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Ue are proud to announce the release of Version 5 of the VISION ACD. 
Version 5 incorporates all changes and clarifications that have 
previously been transmitted only through nemos. This single document 
provides a stable, self-consistent and complete description of the 
VISION processor architecture including 1/0 instructions. A version 
of the companion document "HP/3000 Compatibility Mode" incorporating 
the extended CST structure will be available in October. 

Version 5 of the ACD replaces version 3, and the copy of version 3 in 
your possession must be shredded or returned to Bert Speelpenning at 
CSY. If you wonder what happened to version 4: there is no version 4 
nor will there be. The designation "version 5" for the next major 
release of the ACD somehow gained currency within CSV, and it didn't 
seen particularly fruitful to buck that trend. 

The organization of the architecture description has been thoroughly 
overhauled in order to improve clarity of exposition. These changes 
were sufficiently extensive that it was decided not to retain page or 
section mmbers from version 3; change bars were also abandoned. 
Rather, version 5 is a stand-alone description of the architecture that 
should be read in full by implenentors of VISION-specific products. 

Turning to content, the architecture described in version 5 differs from 
that of version 3 in ways described in earlier memos published by us, 
as well as in other minor ways. These changes are summarized below. 
Their net effect is to make the VISION architecture more streamlined 
auTd easier to implement cost-effectively in hcurdware while minimizing 
the impact on software. 

It is a pleasure to acknowledge the help and cooperation we have received 
in getting the architecture and its description to its current state; the 
implementation teams have been remarkably patient in helping us evaluate 
the effect of proposed chzmges as well as in eusconodating those changes 
we decided to adopt. 

Our main efforts will becoiie focussed on monitoring the progress of 
VISICM implementations; we remain committed to resolve problems in the 
present definition of the VISION architecture that these implementations 
may uncover. 



Summary of significant changes between version 3 and version 5 

1. Virtual address space has been cut back from 74 to 64 bits. 

2. The number of privilege levels has been reduced from 8 to 4. 

3. Object Descriptors have been streamlined to a 4-word fomat. 

4. Procedure linkage has been simplified: the STT-mechanisn is no 
longer required in Vision mode. 

Procedure stack meu'kers have been reduced to three words insteiid 
of four; EXIT can distinguish between markers laid down by CALL 
axyi CALLX, this significantly streamlines exit fron CALL. 

5. Some STATUS bits and other machine state (such as the TCB) have 
been rearranged to allow faster updates to the addreaiing 
environment, such as EXIT or lEXIT. 

6. Synchronization of caches and TLBs when making changes to the 
addressing tables has been Made the explicit responsibility of 
operating system software. 

7. The encoding of instructions has changed. Instructions or pairs 
of instructions now occupy a word or a multiple of words. 
Orthogonality of opcodes and operands has been retained. 

8. 8 General registers have been added. 

9. Instructions dealing with base registers have been separated out. 
Base registers are no longer treated as general operands. 

10. Several instructions that were marginal in terns of speed-up over 
their softwzu'e equivalents were deleted. 

All 16-bit arithmetic and all 12-byte packed decimal arithnetic 
has been deleted from the architecture. 

11. Opcode assignments have been updated. 

12. Several definitions of individual instructions have been streamlined. 

13. Arguments for trap handlers are pushed in the reverse order. The 
trap identification number is now always on top of the stack. 

14. The interrupt structure for I/O and inter-processor communication 
hets been defined and included. 

I/O instructions for PICMB-based systems and for MPB-based syst^s 
have been defined and irK:luded. 

The interface to the Control and Support Processor (CSP) has been 
defit^d and included. 

Not yet included in the Architecture Control Document are : 



1. Instructions to support diagnostic capabilities. 

2. Description of the data structures to support I/O. 
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INTRODUCTION 



CHAPTER 1 



1.1 VISION Architecture Control Document 



This document provides, for reference purposes, the detailed and 
rigorous definition of the machine functions performed by VISION 
compatible computer systems, VISION provides the basis for a 
multitude of fully compatible systems over time which cover a 
broad spectrum of price and performance, benefiting from the 
enploitation of new or evolving technologies and machine 
organizations. 

This is the only authoritative specification of the VISION 
architecture. It provides machine designers and programmers a 
complete description of the machine model which will transcend 
all implementations. 



1.2 Architecture Overview 



The VISION architecture is a product of the experience gained 
with the HP3000, HP300 and FOCUS systems. It provides two 
execution modes. One mode is highly compatible with the HP3000 
and allows execution of HP3000 user level object programs. The 
Vision mode provides advanced information processing capability. 
The Vision mode is designed to retain the general purpose nature 
of its predecessors, but with enhanced ability to effectively 
address both business and technical applications. Vision mode 
is characterized by a powerful and complete basic instruction 
set, a wide range of data types, a stack for data allocation and 
procedure linkage information, data registers to support 
expression evaluation and addressing registers to support an 
extremely large task and system address space, paged memory 
management, a hierarchical protection system, and vector 
processing facilities. 
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1.3 Architecture Control 



The tern "architecture" as used in this document refers to the 
characteristics of the software/hardware interface of compatible 
VISION machines. "Hardware" refers to any combination of 
electronics, electro-mechanics and microcode. 

The notion of Architecture Control has been created at HP to aid 
in the preservation of the investments it and its customers make 
in hardware and software with VISION based products. This 
architectural control document attempts to completely and 
unambiguously describe the features of any model claiming VISION 
compatibility. 

To be successful, the following attributes of the architectural 
control process are stipulated: 

1. This document is the only authoritative specification of the 
VISION architecture. 

2. All models will be monitored for compliance with the 
architure specification. 

3. Deviations from the architecture will be corrected. In the 
rare case when the cost to change the design or to retrofit 
installed machines is excessive in relation to the practical 
value of compliance on that model, deviations are permitted 
when approval is obtained from all affected group managers, 
and appropriate provision is made for the exception in the 
Architectural Control Document. 

4. Implementers are instructed to question any doubtful point in 
the architectural definition rather than make assumptions. 
The specification occasionally leaves out some aspect of the 
operation, or the wording may not be clear. In these cases 
the document should be updated to resolve the point. 

5. Continual maintenance and updating of the architecture 
specification are essential. 

6. At any point in time, the management will entrust maintenance 
of the architecture control document to a person or small 
group. They will be responsible for resolving conflicts, 
creating and reviewing document revisions, stopping debate on 
some issue, etc, through the use of technical and business 
analysis or executive decision making. 
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1.4 Intended Audience 



This document is intended primarily as reference material for 
inplementors of VISION-compatible products; specifically, 
implementors of hardware and microcode, implementors of core 
operating system modules and implementors of Vision compilers. 

The first five chapters can be used as a stand-alone introduction 
to the main VISION features; they cover the VISION addressing 
structure, which is the most distinguishing characteristic with 
respect to its predecessors and current competition in the market. 
To this end these chapters are written in a more tutorial style. 

This document must not he shown to and must not be read by non- 
HP employees. 



1.5 Related Documents 

"HP/3000 Compatibility Mode", internal, January 1982. 

"PICMB ERS", internal. 

"MPB ERS", internal. 

"Interface Protocols for the Control Support Processor for 
VCF60 and VCF50", internal, to appear. 



"A Proposed Standard for Binary Floating Point Arithmetic", 
draft 9.3.3 of IEEE task P754, 



"Time and Frequency Users' Manual", NBS Special Publication 559. 
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1.6 Notations and Conventions 



Algorithms in this document are described in a pidgin PASCAL. 
In these algorithms: 

NAMES in capital letters denote processor registers; 

Names with only the first letter capitalized denote 
temporary or scratchpad values; 

names in lower case denote parameters or operands. 

The notation R[0,.5] denotes a 6-bit field consisting of bits 
through 5 of register "R". 

The notation (R)[0..31] denotes the 32-bit word found at the 
byte address contained in register "R". 

The numbering of bits and bytes is such that the lowest numbered 
bit (byte) contains the most significant information. 

Numbers are given in decimal (default) or in hexadecimal notation 
(when preceded with an "•", e.g. !1A denotes the number 26). 



1.7 ImplCTientation Guidelines 



Experience related to cost-effective implementation of VISION 
hardware and software will be disseminated to other VISION 
implementors when such experience becomes available. Emphasis 
will be on the more subtle implications of the oU"chitectural 
specification; in particular, performance implications. 
Recommended software practices, if sufficiently importsmt to 
the performance of at least one VISION implementation, will be 
included also. 

As an example, all VISION hardware will allow data to be addessed 
on cirbitrary byte boundawies. Yet performance will be degraded 
significantly if data is not aligned on its natural boundaries: 
half words on half-word boundaries, words on word boundaries, etc. 
This effect will be felt on any VISION implementation, to varying 
degrees. 

This document includes some implementation guidelines when it 
was deemed that their inclusion would clarify the issue at hzmd. 
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ADDRESS SPACES 



CHAPTER 2 



2.1 Physical Address Space 



Physical memory is organized in bytes. A byte is a collection of 
8 bits. Each byte in physical memory has its own unique number 
called its physical address. A byte is the smallest addressable 
unit. A physical address is represented by a 32-bit quantity. 
Physical memory is the lomest type of memory in the memory 
hierarchy that is visible to software. Implementations may choose 
to organize physical memory in words (4-byte quantities) instead 
of bytes; they may employ caches to reduce average ciccess time, 
but this must remain transparent to software. 

Input/Output is performed using physical addresses. Software uses 
"logical addresses" (section 2.3) to access memory; these logical 
addresses are translated by address translation hardware (chapter 
3) into the corresponding physical addresses. 



Representation of physical memory: 
01234567 01234567 01234567 01234567 01234567 



01234567 



I !83 I !09 I !B1 | ISA I IFF | 

^ + + + + + 

1 2 3 " I I 4 



!3B 



31 



physical address 



MB 
(physical 

memory 

size) 



(byte access) 



\/ 
01234567 
+ + 

I 16A I 



In this example, the physical address is 3, and therefore the byte 
with identifying number 3 is being addressed. Its contents is 
!6A (01101010). 
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Addresses are also used to access entities larger than a byte. 
(This will apply similarly to logical and virtual addresses). 
In this case, the address reflects the lowest numbered byte. 
The following example shows the result of a 16-bit access using 
physical address "2": 

01234567 01234567 01234567 01234567 01234567 01234567 

+ + + + + +_ _ _ _ _+ + 

I !83 1 !09 I !B1 I !6A I IFF I I !3B I 
+ + + + + +_ _ _ _ _+ + 

1 2 '^ II 3 4 MB 



31 I 
, ^ I 

I 2 1-+ 

4- + 

physical address 



(16-bit access) 



\/ 1 
01234567 89012345 

+ + + 

I 1B16A I 



Physical address space is used for four separate purposes. The 
first purpose is to provide physical pages (see section 2.1.1) 
that support virtual memory (section 2.2). The second is to 
provide a location for the physical page directory (section 2.2.2) 
and hash table (section 3.4) that constitute the foundation for 
the address translation algorithm and therefore must reside at a 
physical address known to hardware. The third is to provide a 
"scratch area" for each processor, transparent to software (see 
chapter 9). This scratch area is used to hold data for which use 
of processor registers would be too expensive; it is also used by 
the I/O channels when they need to communicate with the processor. 
The fourth is to provide addressability for I/O buffers. VISION 
I/O channels only access memory through physical addresses. 



2.1.1 Pages 



Physical memory is divided into physical pages of 4096 bytes each, 
partitioning physical addresses into a 20-bit physical page number 
(PPN) and a 12-bit page offset (POFF), as follows: 



19 20 



31 



physical page number | page offset I 

+ + 

physical address 
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2.2 Virtual Address Space 



In VISION, the virtual address space is extremely large. 
Its size is 2"64 bytes. This address space is so large that 
it frees software for the most part from having to reclaim and 
repack virtual space no longer in use. Uhole data bases can 
reside in virtual space, if so desired. 

Virtual space allows programs to run that require address space 
in excess of the amount of physical memory available on the 
machine. This is accomplished through "demand paging"; a mode 
of operation in which part of virtual memory is kept in physical 
memory and the rest kept on secondary storage; if a request for 
access to virtual memory cannot be satisfied out of physical 
memory, the page containing the virtual address is read in from 
secondary storage (another page may have to be written to 
secondary storage in order to make place for it in physical 
memory) . 

Operating system software policy determines the precise details 
of where virtual pages are kept on secondciry storage and where in 
physical memory a new virtual page is read in. Hardware is only 
responsible for detecting "page fault"s: the condition where an 
access to virtual memory cannot be satisfied out of main memory. 
On detecting a page fault, hardware will transfer control to the 
page fault trap handler (section 7.kk). The operating system 
must then resolve the page fault and transfer control back to 
the user program in a way that makes the occurrence of the page 
fault totally transparent to the user program (except perhaps 
for a noticeable delay) . 

Demand paging in a large virtual space frees writers of software 
from stringent and inescapable limits on programs due to size of 
physical memory. Instead, writers of software for a demand paged 
machine face a concern for "locality of reference". Basically, 
one program's locality of reference is better than emother's if it 
accesses fewer different virtual pages in a comparable time span. 
Programs with better locality of reference will require less page 
swapping and therefore will perform better, other things being 
equal. 

Details on how a virtual address is translated to a physical 
address in VISION are deferred until chapter 3. 
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Two different views of virtual address speice are given here: 
one from the perspective of address arithmetic and allocation, 
the other from the perspective of paging and memory management. 



2.2.1 Virtual Address Space: Virtual Objects 



Virtual address space is orgainized as 2'^32 "virtual objects" 
of 2^32 bytes each: 



virtual offset 



virtual 

object 

number 



+ 



I I 
+_+ 






+ 



2'^32 
virtual 
objects 



-2^32 bytes- 
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This organization of virtual address space corresponds to a 
partitioning of a virtual address as follows: 



31 32 63 

+ + + 

I VON - virtual object number I VOFF - virtual offset! 

+ + + 

virtual address 



The significance of this subdivision is that all address 
arithmetic on a virtual address is performed on the 32-bit 
virtual offset without ever carrying into the virtual object 
number. The virtual object number is never altered by address 
arithmetic. The virtual offset is regarded as a two's complement 
quantity; overflow on address arithmetic is ignored. 
Address arithmetic on virtual addresses occurs during 
translation of logical addresses as described in chapter 3. 



Example: 



31 32 



63 



13 



151 



I virtual address 



31 



I 2"32 - 100 



value to be added 



31 32 



63 



I 13 I 51 I effective 

+ + + virtual address 



Hence address arithmetic, even if nominally involving 64-bit 
quantities, can be implemented in hardware with 32-bit ALUs. 
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2.2.2 Virtual Address Space: Paging 

From a paging perspective, a virtual address (VA) is split into 
a 52-bit virtual page number (VPN) and a 12-bit page offset 
(POFF), as sketched below. (Some VISION documentation refers to 
VA and VPN by the names GSVA and GSVP, respectively. ) 

51 52 63 

+ + + 

1 VPN - virtual page number | page offset I 

+ + + 

virtual address 



A physical page is associated with a virtual page; this will 
typically change over time as pages get swapped in and out, i.e. 
read and written to secondary storage (usually disk storage) . 
At each moment, the state of the association is contained in the 
physical page descriptor (PPD), as follows: 

2 2 2 2 3 3 
01 018901 

I/I PPN (20)|////|R|/|D1 

+-+ + +-+-+-+ 

I VPN - virtual (32) I 

PPD: + page + + 

I number (20) I /////////// I 

I //////////////////////////////// I 

+ + 

where: 

PPN - physical page number (20 bits). 

VPN - virtual page number (52 bits): the number of the 
virtual page currently associated with page PPN. 

D - dirty bit (1 bit): set to one by hardware if the 
contents of the physical page has been changed by 
the processor since it was read in from secondary 
storage, i.e. when the page on secondary storage 
is no longer up to date. 

R - reference bit (1 bit): set to one by hardware if 
the physical page has been accessed since the 
last time softwEure caused the reference bit to 
get reset. 

The PPD has additional fields that are described in section 3.4. 
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2.2.3 The Physical Page Directory (PDIR) 



Each physical page has its own physical page descriptor: all 
PPDs are collected in the physical page directory (PDIR). 



PDIR. PA > + 
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PPN 



\/ 




physical address of 
PPD for physical 
page PPN is found 
as: 

PDIR. PA + 16 * PPN 



physical page directory (PDIR) 

The physical address PDIR. PA is kept in a processor register. 

Note that the PPN field contained in the PPD is redundant with 
the position of the PPD taithin the PDIR. 

2.3 Logical Address Space 



Logical address space provides the third and highest level of 
addressing in the VISION architecture. Logical address space 
serves to insulate and protect programs from each other. At 
the same time, logical address space allows operating system 
software full control over arbitrary patterns of sharing and 
of access protection between user programs. 
All programs run in logical address space. All addresses 
that are directly constructed by a user program are logical 
addresses; these are presented to hardware for address 
translation. Hardware translates logical addresses (via virtual 
addresses) to physical addresses as detailed in chapter 3. 
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A logical address is a 64-bit quantity. The first 32 bits 
identify a "logical object"; logical objects are defined in 
section 2.3.1. The second 32 bits of the logical address contain 
a "logical offset", i.e. a byte offset relative to the beginning 
of the logical object. Below is a depiction of a logical suidress: 



31 32 63 

+ + •♦ 

I LOI - logical object id | LOFF - logical offset I 

+ + + 

logical address 



2.3.1 Logical Objects 



A logical object is a slice of a virtual object that can only be 
accessed through an Object Descriptor, which enforces access 
rights and bounds protection. Object descriptors are detailed 
in section 2.3.2. 



I > 2"31-1 

I > uB 

I > LB 

|> -2"31 

a + + + + 

virtual | | logical object I | 
object + + + + 

1 I 



I logical object | 
+ + 

l> 

I > LOFF 

I > UB-LB 



The figure above shows how two virtual offsets (LB and UB, lower 
and upper bound) are used to delineate a slice of a virtual object. 
Such a slice is called a Virtual Range . The Virtual Range, under 
protection of access rights, constitutes a logical object. 
The bytes in the logical object are numbered from to UB-LB; 
it is this numbering, relative to LB, that is used by the logical 
offset LOFF in a logical eiddress. 
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2.3.2 Object Descriptor Format 



Object Descriptors are 16 bytes in size, 
sketched below: 



The format is as 



OD: 



2 33 
0123 45 6 7 9 01 
+ + + + — + 

I AR ITYPEI EPUO |PR| 
+ + + + — + \ 

I VON - Virtual Object Number I I 
^ + I 

I LB - Lower Bound I > Virtual Range 
^ ^ I 

I UB - Upper Bound I I 
+ + / 



where 



AR = access rights. This field encodes the access 

rights to the object allowed at each of the 

protection levels, as detailed in section 2.3.2.2. 
TYPE= object type. The encoding of this field is 

detailed in section 2.3.2.1. 
EPUO= entry point word offset. This field is meaningful 

only for Vision mode code objects. It is detailed 

in section 5.2. 
= prerequisite level. This field is meaningful 

only for Vision mode code objects. It is detailed 

in section 5.2. 
= virtual object number. Identifies the virtual 

object of which this Object Descriptor defines 

a slice. 
= lower bound. See section 2.3.2.3. 
= upper bound. See section 2.3.2.3. 



PR 



VON 



2,3.2.1 Object Types 



Object types are encoded in a 3-bit field in the OD as follows: 



- Vision mode code object 

1 - Reserved object type 

2 - Vision mode stack object 

3 - data object 



4 - HP3000 mode code object 

5 - HP3000 mode code object, 

subject to PCAL trace 

6 - HP3000 mode stack object 

7 - Reserved object type 
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The object type "HP3000 code object subject to PCAL trace" is 

explained in more detail in the "VISION HP3000 mode document". 

The reserved object types will block access to the object; one 

of these types may become defined in later versions of the VISION 

architecture. 

All other object types are explained fully in this document. 



2.3.2.2 Access Rights 



At each moment, the processor runs in one of two execution 
modes (Vision mode or HP3000 mode) as indicated by the one-bit 
processor state "XM". In Vision mode, four levels of privilege 
are supported, ranging from (most privileged) to 3 (least 
privileged); and the processor will run at one of these four 
privilege levels, as indicated by the two-bit processor state 
"XL". In HP3000 mode, the processor runs in either "User state" 
(which is identified with XL=3) or in "Privileged state" (which 
is identified with XL=1). 

For purposes of protection, accesses are characterized as either 
"read", "write" or "execute". The following chart defines the 
conditions for legal access. Illegal accesses cause a trap as 
defined in chapter 7. 



TYPE (from OD) 



read 



I write 

■+ 

illegal 

IXL <= AR[2..3] 

IXL <= AR[2..3] 

illegal 
IXL <= AR[2..3] 

illegal 



execute 



Vision code object I XL <= AR[0,.l] 

I 
Vision stack object I XL <= AR[0..1] 

I 
data object I XL <= AR[0..1] 

1 
HP3000 code object I XL <= AR[0..1] 

(w/ or w/o trace) I 
HP3000 stack objectlXL <= AR[0..1] 

I 
reserved obj type I illegal 



IXL <= AR[2..3] 
& XM=0 
illegal 

illegal 

IXL <= AR[2..3] 
& XM=1 
illegal 

illegal 



Notes: "<=" means less than or equal in an unsigned 2-bit compare. 
The objects pointed to by special registers P and Q require 
special treatment, as detailed in sections 2.3.5 and 2.3.6. 
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2.3.2.3 Lower and Upper Bounds 

Logical objects are slices of virtual objects protected by a 
lower bound and an upper bound, as sketched below: 



07/31 



OD 



VON 



virtual address space 

+ UB 

+ LB I 

I I 

V V 

+ +-+ + 

I ####################1 

I #################### I 

I #################### I 

|####Guard zone######| : : 

!#### of ######1 

!#### invalid ######! 

!#### virtual ######! 

I ####addresses ######! : 

I #################### I 

I #################### I 

+ + + 

I #################### I 1 log. obj. 1 

+ + + 

I #################### I 
I #################### I 

z z 



I I 

I I 

I 2"32 

I virtual 

I objects 



-2"32 bytes- 



Both lower and upper bound are 32-bit two's complement quantities 
that delineate the logical object; both bounds are inclusive. 
Any address arithmetic (e.g. indexing) involving a logical object 
that causes the virtual offset to stray outside the bounds given 
in the Object Descriptor will result in a trap. (This applies 
only to addresses actually used in accesses, not to preparatory 
address calculations.) 

Though lower and upper bound are two's complement quantities, 
their values must always be positive. It is the responsibility 
of operating software to ensure this. The size of logical objects 
is therefore limited to 2^31 bytes. Note that zero- length objects 
can be supported by having UB = LB -1 in the Object Descriptor. 
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2.3.3 Object Groups 



Object Descriptors belong to the program that is executing; 

more precisely, they are associated with a task. 

It is the responsibility of operating system software to implement 

a policy of protection and security, by setting up only such 

Object Descriptors on behalf of each task as are needed by the 

task to perform its rightful function. 

It is the responsibility of hardware to enforce the access rights 

and bounds protection as contained in the Object Descriptor. 

Object Descriptors are organized in groups in order to facilitate 
sharing of objects among tasks. The VISION architecture provides 
for eight object groups per task. Each group has a data structure 
(Object Descriptor Table, see section 2.3.4) that maps a logical 
object id onto an Object Descriptor. Tasks that share all objects 
in a group can therefore share the Object Descriptor Table for 
that group as well, resulting in reduced duplication of Object 
Descriptors and (as an importsmt side effect) faster task creation. 

Group zero is the sane for all tasks, i.e. logical addresses 
with a zero group selector translate to the same virtual address 
regardless of which task is translating it. 
Groups one through seven are either shared or task-specific, 
completely under operating system software control. 

The 32-bit logical object id (LOI) serves to locate the Object 
Descriptor for the logical object. For this purpose, LOI is split 
into a 3-bit group selector (zero through seven) ani a 29-bit 
logical object number (LON) interpreted relative to the selected 
group: 



012 3 31 

+ + + 

I G I LON - log object number | 

+ — + + 

logical object id 

where 

G = group selector ( 3 bits) ; 
LON = logical object number (29 bits). 
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The format of a logical address can therefore be depicted as: 



07/31 



31 32 



63 



012 3 

+ + + 

I G I LON - log object number I LOFF - logical offset 

+ — + + 



2.3.4 Object Descriptor Table 



Each object group has an Object Descriptor Table (ODT) which is 
a linear collection of Object Descriptors indexed by the logical 
object number. The Object Descriptor Table is itself an object 
in virtual and logical address space and its location is known 
to hardware, as detailed in section 2.3.8 and chapter 4. 
Both virtual lower bound and virtual upper bound of an ODT must 
be multiples of 16. 



012 3 31 32 63 

+ — + + + 

logical address | 4 | LON + | LOFF | 

+-I-+ 



ODTO ODTl 0DT2 0DT3 
+ + + + + + + + 

I I 



/ \ 

0DT4 0DT5 0DT6 0DT7 
+ + + + + + + + 

I II II II I 



I II II I 

I II II I 

+ + + + + + 

V I OD I 

+ + 

I I 

I I 

+ + 



Virtual address of OD = 

virtual address of selected ODT + 16 * LON 



+ + 
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2.3.5 Current Code Object 



In Vision mode, there is a 64-bit Program Counter P that holds 
the logical address of the instruction currently executing. 
Bits P[0..31] contain the logical object id of the object known 
as the current code object. In VISION documentation, PB is used 
as shorthand for the (logical address of the) lower bound of the 
current code object; similarly, PL is used to point to the first 
byte beyond the current code object. 



PB==> 



P==> I 



+ + \ 



> current code object 
I 



+-— + / 
PL==> I I 



Read access to the current code object is allowed; this overrides 
the access right field in the OD. Both LB and UB in the OD for 
the current code object must be multiples of 4. The size of the 
current code object must be no more than 2''24 bytes. It is the 
responsibility of operating system software to ensure LB and UB 
meet these requirements. P will always be even ( PC63]=0 ); this 
is ensured by hardware checks in the EXIT and SEXIT instructions. 
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2.3.6 Current Stack Object 



Two Vision node registers Q and S both hold logical addresses. 
Bits Q[0..31] are at all times identical to bits S[0..31]; these 
identify the logical object known as the current stack object. 
The significance and the use of Q, S and the stack object is 
detailed more fully in chapter 5. In VISION documentation, SB is 
used as shorthand for the (logical address of the) lowest numbered 
byte of the current stack object; SL denotes the first byte beyond 
the current stack object. 



SB==> I 



\ 



Q==> I I I local stack frame > current stack object 

I I / 

+ + 

S==> I I \ 

I I I undefined area 



SL==> I 



H— -+ / 



/ 



Read and write access at any privilege level to the current stack 
object is allowed; this overrides the access rights field in the 
OD for the current stack object. All accesses to the stack object 
must fall within the bounds SB (inclusive) and S (exclusive); this 
overrides the upper bound in the OD for the current stack object. 
Both LB cind UB in the OD for the current stack object must be 
multiples of 4. In addition, UB must satisfy UB < 2''31-4. It is 
the responsibility of operating system software to ensure that LB 
and UB meet these requirements. 

All changes to Q and S must satisfy SB <= Q <= S <= SL. 
(Q and S only change as a side effect of certain instructions 
such as CALL and EXIT. See chapter 6 for detail.) 



2.3.7 Nil Object 



Logical object zero in group zero (logical object id = 0) is 
inaccessible to all software. Operating system software is 
responsible for maintaining the OD for LOI=0 such that no 
accesses are legal. To do so, it suffices to set UB = LB - 1. 
This allows the nil pointer to be represented conveniently by 
a logical address consisting of 64 zeros. 
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2.3.8 Group Descriptors 



A Group Descriptor (GD) serves to locate an Object Descriptor 
Table for a particular group. The Group Descriptor for the ODT 
for group is kept in processor registers: it is meichine state. 
Group Descriptors for groups 1 through 7 are contained in the 
Task Control Block (see section 2.3.9). GDs occupy 16 bytes 
and have the format as shown: 



GD: 



////////////////////////////// 1 


VON — 


virtual object 


number I 


LB ~ 


lower bound 


1 


UB ~ 


upper bound 


1 



The first word of the Group Descriptor will be detailed in 
section 4.5. The remainder of the Group Descriptor contains a 
Virtual Range, as in an Object Descriptor. The Virtual Range 
locates the ODT in virtual space. 

Operating system software is responsible for ensuring that LB 
and UB are multiples of 16, so that all ODs in the ODT will be 
aligned on 16-byte boundaries. 



2.3.9 Task Control Block 



The Task Control Block (TCB) of the currently executing task is 
a software data structure whose location and layout is known 
to hardware. The 64-bit virtual address of the TCB is kept in a 
processor register TCB.VA. The value of this virtual address 
can be changed by the "LAUNCH" instruction when performing a 
task switch. 

Operating software must ensure that the TCB of the currently 
executing task is resident in physical memory, TCBs for tasks 
not currently executing are not in any way constrained by the 
VISION architecture. The full layout of the TCB is given in 
section 4.7. Only the part of the TCB involved in defining 
logical address space is shown here. 
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TCB.VA ==> I ///////////////// I 
I ///////////////// I 
I ///////////////// I 
I ///////////////// I 



Hl6 I GD 
I for 
I group 
one 



+32 I GD I 

i for I 

I group I 

I two I 



+112 I 



GD 
for 
group 
seven 



+128 I ///////////////// I 
The TCB virtual address TCB.VA must be a multiple of 16. 
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ADDRESS TRANSLATION 



CHAPTER 3 



Software running on the VISION architecture interacts with 
memory continually. Software is made up of instructions that 
must be fetched from memory; memory is read, the data examined, 
processed, and the results stored back into memory. 
To perform these memory accesses, hardware computes logical 
addresses that are then translated to physical addresses. 
Computing logical addresses can be as simple as incrementing 
the program counter (P) on each instruction fetch, or it may 
involve adding together the displacement value out of an 
instruction with the contents of the offset part of a base 
register in order to form what is called the "effective logical 
address". Logical address computation is detailed in chapter 6. 
This chapter explains address translation in VISION. Address 
translation always accompanies a request for access to the 
memory system; hence it proves convenient to explain address 
translation in the context of such an access. 



3.1 An Access — its characteristics 



A memory access in Vision mode has these three characteristics: 



a) a logical address, 

b) a length in bytes, 

c) a type of access, 



LA 

L 



read/write/execute/semaphore- read 



Read and write accesses can be performed on entities that vary 
in length from 1 through 16 bytes. Execute access (instruction 
fetch) can be performed on multiples of 4 bytes. 
Semaphore- read is a special type of access that can be performed 
only on 4- byte quantities; it consists of a read followed 
indivisibly by a write of all ones. For purposes of address 
translation, the indivisible nature of semaphore-read is of no 
import; we can treat it in this chapter simply as a read 
followed by a write to the same address. 

A multi-byte read (L>1) is implemented as if it were a sequence 
of single byte reads at addresses LA, LA+1, .. , LA+L-1, the 
results of which are collected into a hardware buffer area. If 
any of the single-byte reads fails (e.g. bounds violation or 
page fault) the single-byte reads that did succeed are non-_ 
destructive: as far as software can tell, no machine state is 
modified. 
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A multi-byte write is implemented as if it were a series of 
single-byte writes at addresses LA, LA+1, .. , LA+L-1, with the 
proviso that hardware implementations are free to perform the 
single-byte writes in any order. This means that if any of the 
single-byte writes fails (e.g. bounds violation or page fault), 
software cannot make any assumptions about the state of the 
addressed memory. 

Note: an instruction that has a read-write operand (an operand 
that is both read and written as part of the same instruction) 
must never write any bytes of the operand unless it can 
guarantee that writing all bytes of the operand will be 
completed. (This accomplished trivially on single-processor 
systems by prefetching the operand; on shared-memory multi- 
procesor systems it requires that the PDDEL instruction allow 
any on-going instructions to first complete. ) 

Instruction fetch is like read in that its effect can be viewed 
as a sequence of byte-reads into a hardware buffer area, 
transparently to software. 

Uithout loss of generality it is then possible to describe 
address translation in terms of single-byte accesses only. 



3.2 Access Algorithm 



Accessing a byte at logical address LA can be described by an 
algorithm, developed in detail over the next feu sections, 
that requires the following items of machine state as input: 

XL - execution level of the hardware 

TCB.VA - virtual address to the TCB of the currently 

running task 
PDIR.PA - physical address of the PDIR, the physical 

page directory 
HASH. PA - physical address of the Hash Table 



3.2.1 Schematic overview 



The next page shows an overview of address translation for 
accessing a single byte at logical £iddress LA. 
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3.2.2 Hardware Shortcuts in Address Tramslation 


1 locate ODT from I 
1 GO for group G I 

V 


The architectural definition of ciddress translation should by 
no means be read as a precise indication of all the steps 
performed by hardware in their precise order. 
In order to be cost-effective, hardware "must cheat but not 


1 locate 00 for LON | 
1 in this ODT 1 


get caught". Just as a cache holds recent memory accesses in 
a faster but smaller type of memory, so can hardware employ 


1 

V 


various types of devices to speed up address translation by 
setting aside recent results of address translation. The most 


/TYPE and access \ 
/ rights OK for \ no 


trivial example would be locating the eight ODTs. Hardware may 
do this only once after a task switch and keep the virtual range 
of each ODT for the current task in some internal register. 
This involves a trade-off between the speed of the task switch 
itself and the speed of all subsequent address translations. 
Hardware may also choose to keep recent pairs of 
(logical address, physical address) around, or recent pairs of 


\ at level XL? / 
\ / 
1 yes 

V 


(compute virtual address i 
|VA = [ VON 1 VOFF ] 1 
Inhere VOFF = LB + LOFF | 
II 


(LOI, OD) and/or recent pairs of (VPN, PPN). 

Any such association of recent pairs that are presumably useful 
in bypassing parts of the address translation algorithm is 
referred to in this document by the name "TLB", short for 


1 

V no 


"Translation Look-aside Buffer". 


/LB <= LOFF <= UB \ > bounds violation 

\ ? / 

1 yes 

V 


Address translation is effected through address translation 
tables that are in part task-specific, in part system-wide. 
Changes in address translation are relatively infrequent, e.g. 
(VPN, PPN) associations become outdated only on page swaps, 


1 extract VPN=VA[0. .51] | 
land P0FF=VA[52..63] I 
1 1 


(LOI, OD) associations become outdated only on task switches and 
on explicit changes to ODTs brought about by the object 
management facility in VISION operating system software. 


1 

V 


Because these changes are relatively infrequent, and because the 
situations in which they arise are under explicit operating 


/search for VPN \ no 


system software control, it is particularly cost-effective to 
recognize architecturally the existence of some kind of TLB, 
while leaving the exact nature of the TLB to the discretion of 
the hardware implementation. 


\ , / 

1 yes 

V 


IPPN is inden in PDIR | 
1 where VPN was found I 
1 1 


The existence of the TLB is recognized architecturally in VISION 
by requiring operating software to issue explicit instructions 
that warn hardware of the fact that the conditions for address 


1 

V 


translation have changed and that information in the TLB may no 
longer be up to date. Address translation look-aside in VISION 


IPA = [ PPN 1 POFF ] 1 
1 1 


hardware tlrerefore need not be completely transparent with 
respect to changes in addressing tables. 


1 

V 




1 access byte at PA I 
1 1 
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3.3 Logical to Virtual Address Translation 



Logical to virtual address translation for logical addresses in 
groups one through seven is similar, but not identical, to 
translation of logical addresses in group zero. The differences 
are limited to the way the OCT for the group is located. 
In actual hardware implementation, even these differences may be 
absorbed in the work performed on a task switch after which the 
logical to virtual translation is done in the sane way for all 
groups . 



3.3.1 Locating the ODT in Virtual Space 

Starting out with a logical address: 

012 3 31 32 63 

+ + + + 

I G I LON I LOFP I 
+ + + + 



it is first necessary to locate the ODT for group G in virtual 
space. 



3.3.1.1 Locating the ODT for Group Zero. 



Locating the ODT for group is very simple: the Group 
Descriptor for group (GDO) is kept in a processor register. 
This Group Descriptor includes a Virtual Range that delineates 
ODTO in virtual space. See section 4.5 for more detail. 



3.3.1.2 Locating the ODT for a Group Other than Zero 



Locating the ODT for group G, where G>0, requires accessing 
the TCB of the currently executing task in order to obtain 
the Group Descriptor for group G. The TCB is ciccessible to 
hardware through the TCB.VA virtual address; TCB.VA is kept 
in a processor register. 
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In practice, hardware implementations may choose to access 
the TCB once on I EXIT and copy the seven Group Descriptors 
into processor registers. 



3.3.2 Locating the OD for the Logical Object 



Having located the ODT in virtual space through the Group 
Descriptor GD, the Object Descriptor OD of the logical 
object can now be found by computing: 



I VON (from GD) I LB (from GD) + 16 * LC»J I 

+ + + 

virtual address of OD 



This OD can now be accessed in virtual space using the procedure 
described in section 3.4. Note: a hardware implementation may 
choose to cache recent pairs of (LOI, OD). 



LON I LOFF 

+ 

logical address 



GDI 



OD I 

+ + — 



+ + 



/ I AR I TYPE I //////////// 1 

V / + + + + 

— / I VON - virt obj nr I 



\ I LB - lower bound I 

\ + ^ 

\ I UB - upper bound I 
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3.3,3 Computing the Virtual Offset 



Having located the OD for the logical object, type checks and 
access right checks can now be performed. Software must be 
informed of any violation uncovered in these checks (through 
the trap mechanism detailed in chapter 7) 

From this OD amd the logical offset LOFF, the virtual address 



VON 



VOFF 



can now be computed as: VOFF = LB + LOFF (in wrap-around 32- 
bit two's complement arithmetic). However, software must be 
alerted of a bounds violation if LB <= VOFF <= UB does not hold. 



3.4 Virtual to Physical Address Translation 



Translating a virtual address (64 bits) to a physical address 
(32 bits) means translating a 52-bit virtual page number (VPN) 
into a 20-bit physical page number (PPN) and carrying the 12- 
bit page offset (POFF) along, as indicated in the sketch. 



virtual eiddress 



\/ 










51 52 63 


1 


VPN 




1 POFF 









19 20 31 




1 

+ — 


PPN 


1 POFF 

+ 
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3.4.1 Physical Page Directory Search 



The translation of a virtual page number VPN into a physical 
page number PPN may give different results over time as pages 
are swapped in and out of physical memory. It is the 
responsibility of operating system software to maintain the 
page directory PDIR (see section 2.2.3) with the help of the 
instructions PDINS and PDDEL. The page directory PDIR gives 
the current association of physical pages with virtual pages. 
For each physical page PPN there is a physical page descriptor 
PPD (see section 2.2.2) that describes the VPN currently 
associated with it. In principle, it is therefore sufficient 
to do a linear scan over the PDIR looking for a PPD that has 
the correct VPN in it; this identifies the proper PPN or else 
it establishes that no physical page is associated with this 
VPN and a page fault is thereby indicated. 
However, a linear scan would be unacceptably slow even when 
hardware keeps enough recent pairs (VPN, PPN) around in a TLB 
to produce an excellent hit rate. The entire PDIR would have 
to be scanned in order to establish, for instance, that the 
virtual page is nowhere in physical memory (page fault trap). 
The VISION architecture therefore defines a hashing technique 
in order to speed up the search for the right virtual page 
number and to speed up detecting a page fault condition. 



3.4.2 Overview of Hash Table and Hash Chain 



In order to avoid having to scan large parts of the PDIR on 
a virtual page to physical page tremslation, a hash value 
is computed from the VPN: 

H = hash( VPN ); 

where the hash function "hash" is described in section 3.4.5. 
All PPDs in the PDIR of virtual pages that have the same hash 
value H are chained together and the beginning of the chain 
can be found in the hash table HASH. These chains and the 
hash table HASH are maintained with the help of the PDINS and 
PDDEL instructions. 

The number of entries in the HASH table (which must be a power 
of two) should be at least of the same order as the number of 
entries in the PDIR in order to keep the chains aujceptably 
short. The number of entries in the PDIR is determined by the 
number of physical pages in the hardware configuration. 
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Note that by its very nature the pages that make up the PDIR 
itself must never be absent and the entire PDIR must be 
contiguous in physical memory. The VISION architecture 
places the same constraints on the HASH table. Both PDIR 
and HASH are located through processor registers HASH. PA and 
PDIR. PA that contain the physical address of each table. 

51 
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VPN 



I hash I 
I algorithm I 



HASH. PA 



HASH table 



H + >| PPD addr I- 



+ hash 
bucket 



PDIR. PA 



PDIR 



head of + >|VPN|neKt PPD| + =====>PPN 

hash chain + + I 

I I I hash 
I I I chain 

+— + * I 

Ivpnl |< + 



Overview of virtual to physical page translation 
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Note that the only actions ever performed on a 52-bit VPN are: 

a) computing the hash function 

b) comparing for equality against a field in the PPD. 

The latter can be implemented by tBo 32-bit compares. The VPN 
acts purely as a tag and never participates in 52-bit arithmetic. 

3.4.3 The Hash Table 

The Hash Table is a collection of "hash buckets", each 32 bits 
long. The physical address of the hash bucket is calculated as 

HASH. PA + 4 * H, Where H = hash{ VPN ), 

as described in section 3.4.5. 



The format of a hash bucket is: 

1 

+_+ 

|S| PPD locator 

+-+ 



31 



< bucket for H. 



PPD locator : this value is the physical byte address of 
one of the PPDs associated with a virtual page that 
hashes to the value H. There may be more than one 
such PPD, in which case the locator will simply 
point to the head of a linked list; or there may 
be none, in which case the PPD locator will be zero. 
A zero value for the PPD locator will indicate a 
page fault. 

S = semaphore bit. Available for use by PDINS and PDDEL 
to synchronize changes in the HASH and PDIR tables 
in a shared-memory multiprocessor system. Outside 
such use, hsirdware may assume that its value is zero. 



Note: To avoid ambiguity in the definitions shown above, the 
PDIR must reside in the first half of physical address 
space. The PDIR must not start at physical page zero. 
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3.4.4 PPD Pormat to support Hashing and Related Functions 

Each PPD is a 16-byte entity whose physical address is related 
to the physical page number PPN through the formula 

physical address of PPD = PDIR.PA + 16 * PPN. 

The PPD format is detailed below: 

2222233 
01 0178901 

+_+ + + +_+_+_+ 

|S| PPN (20)|MBZ IDBEIRICIDI 
+_+ + + +_+_+_+ 

I VPN - virtual page number (32)1 

+ + + 

I (20)1 MBZ 1 

+ + + 

I next PPD locator I 
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where 



VPN = virtual page number. This is the virtual page 
currently associated with the physical page PPN. 
If this field matches the VPN of the virtual address 
being translated, the right physical page has been 
found. If no match occurs, the PPD at the "next PPD 
locator" should be checked for a match. 

next PPD locator: a physical byte address used to locate 

the next PPD that contains a virtual page number that 
hashes to the same HASH value as VPN. This field is 
consulted only if the VPN in the current PPD does not 
produce a match. If the entry is then found to be 
zero, it means that the end of the chain has been 
encountered, and a page fault trap is indicated. 

PPN = physical page number. This field is redundant as it 
can be easily derived from the physical address of 
the PPD, but it is available for hardware use. 
It is the responsibility of operating system software 
to ensure that PPN is at all times consistent with 
the PPD address. 

D = dirty bit. Set to one by the processor on each write 
access to the page. To be cleared by operating syste 
software when the page is written out to secondary 
storage. D is not affected by I/O traffic. 
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C = checkpoint dirty bit. Set to one by the processor on 
each write access to the page. To be cleared by 
operating system software. It may be used at the 
discretion of the operating system. 

R = reference bit. Set to one by the processor on each 
access to the page. Operating system software will 
clear this bit on a periodic basis such that finding 
the reference bit set can be interpreted to mean that 
the page was referenced recently (either explicitly 
by the program or implicitly by certain prefetch 
hardware). R is not affected by I/O. 

DBE = debug breakrange enabled. Set to one by operating 
system software whenever the page contains any part 
of the system or local breakrange. Hardware bypasses 
the breakrange checks when accessing a page with 
DBE zero. See section 5.3.2 for more detail. 

S = semaphore bit. For hardware use in synchronizing 
write access to the reference and dirty bits in a 
shared-memory multiprocessor configuration. Before 
and after such use, S must be zero. 

MBZ = must be zero. It is the responsibility of operating 
system software never to introduce a non-zero value 
into this entry. Hardware may assume the field is 
zero and it need not check this. 



SPECIAL NOTES: 

1) To avoid ambiguity in the above definition, the PDIR must 
reside in the first half of physical address space, yet must 
not start at physical address zero. The physical address 
PDIR.PA must be a multiple of 16. 

2) Software must not access (read or write) the PPDs, but must 
instead rely on special instructions to deal with them: 

PDDEL - remove a PPD from its hash chain 
PDINS - insert a PPD in its hash chain 
TESTREF - read and reset reference bit 

Only a PPD not currently in a hash chain (e.g. after PDDEL 

has extracted it) may be accessed by software. 

These restrictions simplify hardware synchronization. 

3) Shared-memory multiprocessor implementations that use 
write- to TLBs may use the MBZ field as a semaphore area in 
order to synchronize writing out dirty aM reference bits. 
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3.4.5 The Hash Algorithm 



The purpose of the hash algorithm is to break up the long list 
of physical page descriptors PDIR into a large number of short 
chains so that, in order to find the physical page corresponding 
to a given virtual page, only the physical page descriptors in a 
single short chain need be scanned. In order to keep the chains 
short, the hash algorithm must succeed at producing different 
hash values for those virtual pages that are likely to be in use 
simultaneously. The hash algorithm used in VISION accomplishes 
that by producing different hash values for those virtual pages 
that are allocated by the operating system closely together in 
time. The VISION hash algorithm cannot succeed in doing so 
mithout some minimum cooperation from operating system software. 
In particular, allocation of virtual memory is assumed to be 
done either contiguously within the same virtual object or else 
in units of an entire virtual object. The hash algorithm can be 
defeated by the operating system allocating virtual memory in 
2''25 byte slots, for instance. 

The hash algorithm presented here is really a family of hash 
algorithms, parameterized by the single quantity K. It takes 
a virtual page number as input and produces a 32-bit number: 



H[0..31-K] 
H[32-K..31] 



:= 0; 

:= hash( VPN ); 



The number of hash buckets in the HASH table must be a power 
of two: 2"K. The HASH table length is therefore 4*2^K bytes. 

The hash algorithm is sketched below. A PASCAL version of the 
hash algorithm is given on the next page. 



Virtual Page Number (VPN) 



12 3 4 5 
0123456789012345678901234567890123455789012345678901 

I II II II I 

|<___||< 1|<— - 

/ K bits / 

/ / 

/ field 3 / 

/ " / 

K-min(20-K,K) min(20-K,K) 

bits bits 



K bits 
Field 1 



Field 2 MSB 



Field 2 LSB 
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a) Field_l is defined to go from bit 52-K to bit 51. 

b) Field_2 is divided into two parts. The most significant bits 
are defined to start at bit 32-2*K+min(K,20-K) and go to bit 
31-K, Note that this part is empty for K<10, 

The least significant bits are defined to start at bit 32 or 
52-2*K, whichever number is the greatest, and go to bit 51-K. 

c) Field_3 is defined to go from bit 32-K to bit 31, 

d) Field_lR is defined to be Field_l with the bits collected 
in reverse order, 

e) The K-bit hash value is obtained from taking the bit-wise 
eKclusive-OR of the fields Field_lR, Field_2 and Field_3. 



Here is the PASCAL definition: 



const K = {value between 5 and 17}; 
type bitfield: array[0..31] of 0..1; 
virtpageno: array[0..51] of 0..1; 
function hash (VPN: virtpageno): bitfield; 
var i,j,m,n: integer; F1,F2,F3,H: bitfield; 
begin 

j := 51-K; m := 31-K; n := 52-K; 
for i := 31 downto 32-K do 
begin 

Fl[i] := VPN[n]; 
n := n + 1; 
F3[i] := VPN[i]; 
if j >= 32 
then begin 

F2[i] := VPN[j]; 

j := J-1; 
end 
else begin 

F2[i] := VPN[m]; 
m := m-1; 
end; 
end; 

for i := to 31-K do H[i] := 0; 

for i := 32-K to 31 do H[i] := Fl[i] xor F2[i] xor F3[i]; 
hash := H; 
end {hash}; 
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3.4.6 Page Faults 



The virtual to physical address translation either succeeds in 
finding the physical location corresponding to the virtual 
location, or it fails. Failure gets reported to software as 
a page fault trap. Operating system software is responsible 
for making room in physical memory and bringing in the virtual 
page from secondary storage and returning control so that the 
instruction originally causing the page fault can now make 
progress. It is the responsibility of operating system 
software to maintain data structures that allow it to locate 
virtual pages on secondary storage. It is the responsibility 
of hardware to recover the machine state, on detecting a page 
fault, that allows the current instruction to be restarted 
(or "step- restarted", see chapter 7) transparently to the 
user program after the page fault has been resolved by 
operating system software. 

Certain programs that make up the operating system software 
cannot themselves sustain page faults during their execution 
either for inherently logical reasons (e.g. the driver for the 
paging device must always remain in physical memory) , or for 
timing-dependent reasons. Guaranteeing that all virtual pages 
accessed by such operating system software are present in 
physical memory ("resident") is itself the responsibility of 
operating system software. There are no architecturally defined 
data structures that prevent physical pages from being swapped 
out. 
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PROCESSOR REGISTERS AND MACHINE STATE 



CHAPTER 4 



This chapter describes the various registers that are available 
for use by Vision software and also the processor registers that 
support the VISION addressing structure. 

Vision offers 16 programmable registers of 32 bits for general 
program use and 8 registers of 64 bits specifically to hold 
logical addresses. VISION'S vector processing capability is 
supported through 8 vector registers, each capable of holding up 
to 256 elements, each element being capable of holding a 128-bit 
IEEE floating point number or any smaller data type. 
Various status registers record conditions or modify behavior of 
instruction execution. 



The processor registers described belora all exist outside the 
address space. Registers do not have addresses. No "normal- 
looking" writes to memory will in fact write to a register. 
All changes to register values are explicit, i.e. through use of 
instructions such as MOVEf/tSP or as side-effects of instruction 
execution as explicitly provided for in chapter 6. 
This allows low-end VISION hardware implementations to implement 
some of the less frequently used processor registers by using 
hardware- reserved memory locations; locations in physical memory 
that are not mapped into virtual or logical address space. 
Chapter 9 provides details on where hardware-reserved memory 
should be located. 



4.1 General/Index Registers 



In Vision mode, software has access to 16 registers XO, XI,.., 

X15, each of which is 32-bits wide. These registers can be used 

for general expression evaluation, for passing parameters to 

procedures, for allocation of local variables in a procedure and 

for holding index values in address calculations. 

Registers can be used singly, in pairs or quads to hold values 

comprising 32, 64 or 128 bits. 

The registers are not typed. Their contents are interpreted 

according to the type of operation being performed. 
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4.2 Base Registers 



In Vision mode, software has access to 8 registers BO, 81,.., B7, 
each 64 bits wide and capable of holding a logical address. 
Registers 86 and 87 are better known as Q and S, respectively; 
Q and S support stack addressing and the calling mechanism 
described in chapter 5. The base registers can be loaded and 
manipulated as detailed in section 6.2.5. 



4.3 Program Counter 



The Vision program counter is a 64-bit register P. It contains 
a 64-bit logical address that points to an instruction in the 
current code object. The value of P changes as instructions are 
executed; normally, P is incremented to point at the next 
instruction in sequence. Branches and other transfer of control 
instructions will cause P to change explicitly. External events 
such as external interrupts may preempt the currently executing 
program and force execution to continue at a well-defined place. 
Transfers of control other than branches will leave a record of 
the old value of P; this is detailed in chapter 5. 



4.4 Status Registers 



The status registers combine various fields of machine state in 
a convenient ajid compact form. There axe six 32-bit words of 
status, divided into four logical groups: 

1) STATUSA — The SIATUSA register represents the part of 
the machine state that is local to the execution of the 
current code object. STATUSA is shown as an 8-bit 
register left- justified in a 32-bit word. STATUSA[0..7] 
is stored in the procedure marker for an external 
procedure call and restored on the corresponding EXIT. 
Similarly, STATUSA is stored in an interrupt marker on 
an interrupt (external or internal) , and restored on the 
corresponding lEXIT. 
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2) STATUSB — The STATUSB register represents the part of 
the machine state that is local to a task activation or 
the activation of an interrupt handler. For tasks not 
currently active (suspended by an interrupt or by the 
DISP instruction) the value of STATUSB is stored in the 
interrupt marker for that task. STATUSB is restored from 
the interrupt marker on I EXIT (or LAUNCH). STATUSB is 
initialized to a known value on an external interrupt and 
on entering the dispatcher. 

3) STATUSC ~ The STATUSC register represents the part of 
the machine state that is local to a CPU/processor. 
This means that the STATUSC register is replicated for 
each processor in a shared-memory multi-processor system 
and its values are specific to each processor in that 
system . 

4) STATUSD ~ The STATUSD register represent the most 
global of all status information. This status is shared 
among all CPUs/processors in a shared-memory multi- 
processor system. This implies that a change to STATUSD 
must be communicated synchronously to all processors. 



The next page shows an overview of all status registers with 
their constituent fields. 
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12 3 4 567 8 
+_+ — + + + + + +_ 

SIATUSA |1|XL|SIT|IIP|DBP| | | 
+_+ — + — + — + + — + +_ 



11111 
12 3 4 



012 3 4 5 

+ + — + + + — + — + 

STATUSBl I |PTE|DISP|vector|TCE|XTL| 



11 11 12 
2 3 4 5 9 



2 22 33 
0134 23 45 90 7 89 01 
+_+ — + + — + — + + + — + — + 

STATUSB2 I IFPCI TE |CBA|CBB| EF | |CC| | 
+-+ + + + + + + — + — + 



2 2 2 3 3 
7 8 9 1 



STATUSCl 



DDC 



IXMlICSlDRFlIEl 



STATUSC2 



1 1 
5 6 



IMR 



12 3 

+-+ + — 

STATUSD I IDRLI 

+-+ + — 



REVCODE 
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4.4.1 STATUSA Register 
4.4.1.1 Format 



12 3 4 567 8 
+_+ — + — + — + — + — + +_ 

STATUSA |1|XL|SIT|IIP|DBP| | | 
+-+ — + + + + + +- 



STATUSA — Procedure Status 



4.4.1,2 Summary 



Field Name 



Bit Positions 



XL - Execution Privilege Level 1-2 

SIT- Single Instruction Trace 3 

IIP- Instruction In Progress 4 

DBP- Debug Brealq)oint Pending 5 



4.4.1.3 XL - Execution Privilege Level 



This specifies in which of the four protection rings the 
processor is currently executing. Ring (or Level) is 
most privileged and ring 3 is least privileged. 

Change of execution privilege level is accomplished by one 
of three instructions. The CALLX instruction can grant 
extra privilege or leave it the same, but will never take 
privilege amay. The EXIT instruction (or lEXIT) may take 
privilege away or leave it the same, but will never grant 
extra privilege. 

The CALLX instruction determines the privilege level of the 
target code object from the execute access right field in 
the OD for the code object. This field identifies the least 
privileged level at which code within that object may 
execute. Calls to that object automatically begin execution 
at that level, or the level of the caller, whichever is more 
privileged. 
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The EXIT instruction restores the privilege level of the caller 
if caller and called procedure reside in different code objects. 
It does this by extracting the privilege level of the caller 
from the procedure stack marker after applying a consistency 
check on it. EXIT may never grant the caller more privilege 
than the current privilege level. 



4.4.1.4 SIT ~ Single Instruction Trace 



This bit can only be set as a side effect of an external EXIT. 
Uhen this bit is found set at the completion of an instruction, 
a trap is taken. This allows tracing the execution of softwcire 
one instruction at a time. The SIT bit is automatically cleared 
as part of the trap initiation. 



4.4.1.5 IIP — Instruction In Progress 



Some instructions can be interrupted before they are completed. 
These instructions are composed of "steps", as detailed in 
chapter 6. Uhen such an instruction is in fact interrupted, the 
IIP bit is set and certain information is pushed onto the stack. 
Uhen the instruction is resumed after an lEXIT, finding IIP set 
indicates to hardware that the instruction is being resumed 
rather than restarted, and hardware acts accordingly. A similar 
situation arises when a "step-restartable" trap occurs in an 
interruptible instruction. The EXIT instruction that concludes 
the trap handler will restore the IIP bit and this indicates to 
hardware that some instruction steps have already been completed. 



4.4.1.6 DBP ~ Debug Breakpoint Pending 



DBP is set to one by hardware whenever an instruction modifies 
one of the bytes in the system breakrange or the task breakreuige 
(subject to the Debug Ring Level described in section 4.4.4.3). 
If the DBP bit is found set at the completion of an instruction, 
a debug trap is taken. 

The DBP bit is cleared as part of the debug trap initiation. 
See section 4.8 for more detail. 
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4.4.2 STATUSB ~ Task/Interrupt Status 

4.4.2.1 Format 

11111 3 

012 345 01234 1 

STATUSBl I |PTE|DISP|vector|TCE|XTL| | 

STATUSB ~ Task/Interrupt Status - Privileged 



11 11 12 2 22 33 

0134 23 45 90 7 89 01 

SrATUSB2 I IFPCI TE |CBA|CBB| EF | |CC| | 



STATUSB — Task/Interrupt Status - User Accessible 
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4.4.2.2 Summary 



Field name 



Uord Bit Positions 



PTE ~ Procedure Trace Enable 
DISP ~ Dispatcher Running Flag 
vector — Vector Register Control 
TCE ~ Task Clock Enable 
XTL ~ EXIT threshold level 
FPC — IEEE Floating Point Control: 
Projective/Affine Mode 
RM - rounding mode 
TE — Trap enables: 

Floating Point Operations: 
FLDVDZE — Divide by zero 
FLOVFE ~ Overflow 
FLINVE — Invalid Operation 
FLUNFE ~ Underflow 
FLINXE ~ Inexact Result 



Bl 


3 


Bl 


4 


Bl 


5-10 


Bl 


11 


Bl 


12-13 


B2 


1 


B2 


2-3 


B2 


4 


B2 


5 


B2 


6 


B2 


7 


B2 


8 
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Field name 



Integer Operations: 
INTDVDZE— Divide by zero 
INTOVFE ~ Overflow 
Decimal Operations: 

DECDVDZE— Divide by zero 
DECOVFE ~ Overflow 
CBA ~ Conditional Break Enable, A 
CBB ~ Conditional Break Enable, B 
EF ~ Exception Flags: 

OVF ~ Overflow 
DVDZ — Divide by zero 
Floating Point Operations: 
FLINV ~ Invalid Operation 
FLUNF — Underflow 
FLINX — Inexact Result 
CC ~ Condition Code 



Ford 


Bit positions 


82 


9 


B2 


10 


B2 


11 


B2 


12 


B2 


13 


B2 


14 


B2 


15 


B2 


16 


B2 


17 


B2 


18 


B2 


19 


B2 


28-29 



4.4.2.3 PTE 



Procedure Trace Enable 



Uhen PTE has the value one, all procedure calls (CALL, CALLX 
and BRX) will cause a restartable trap, subject to the value 
in the DRL field in STATUSD. 



4.4.2.4 DISP ~ Dispatcher Running Flag 



DISP is one when the dispatcher is running. The dispatcher runs 
on the bottom of the Interrupt Control Stack. Because DISP is 
part of STATUSB, it gets saved in the Interrupt Marker (and then 
cleared) . This makes it possible for lEXIT to determine, as it 
is removing an interrupt marker, whether to return to another 
interrupt handler or whether to resume or restsirt the dispatcher. 
The DISP bit in the Interrupt Marker must not be modified by 
software. 



4.4.2.5 vector ~ vector register status 



The vector capability of the VISION architecture is described 
in section 4.11. 
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4.4.2.6 TCE — Task Clock Enable 



Uhen this flag is set to one, the task clock will be running. 
This means that the task clock value will be incrementing 
itself at a fixed rate, Uhen TCE is clear, the value of the 
task clock will not change unless explicitly changed by program 
control. See section 7.2. 



4.4.2,7 XTL ~ EXIT Threshold Level 



On executing the EXIT instruction, hardware checks to see if 
the execution privilege level is being changed to a privilege 
level less privileged than the value in the XTL field. If so, 
EXIT mill instead trap out and transfer control to the INSXTL 
trap handler. See section 5.3.6. 



4.4.2.8 FPC — IEEE Floating Point Control 



The IEEE floating point standard govens floating point operation 
in Vision mode. Refer to that publication for further detail. 

Projective/Affine mode: 
0: Projective mode 
1: Affine mode 
This affects the way infinity is treated. 

Rounding mode: 

0: round to nearest unit (breaking ties by rounding to 

even value) 
1: round toward plus infinity 
2: round toweird zero 
3: round toward minus infinity 



4.4.2.9 TE & EF — Trap 8= Exception Flags 



The TE (trap enable) and EF (exception flags) fields are for a 
number of conditions which can occur during the execution of an 
instruction which may require special handling by the user 
program. Five of these relate to floating point operations 
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and are defined by the IEEE standard. Integer data types follow 
the normal rules for 2's complement arithmetic whereas decimal 
data types are described in section 6.3. 
Uhen an exception condition occurs, the trap enable bit is 
consulted to determine whether the exception should result in a 
trap. If the trap is disabled, the corresponding exeption flag 
is set. The exception flags act as "sticky bits" that record 
the occurrence of exception conditions at any time during which 
traps were disabled. Hardware never resets the exception flags; 
nor will an exception flag, when set, cause a trap when the trap 
is subsequently re-enabled. 



4.4.2.10 CBA & CBB ~ Condition Break Enable Flags 



The CBA and CBB fields control the operation of the CHECKA and 
CHECKB instruction, respectively. CHECKA causes a trap when CBA 
is found set, and acts as a NOP when CBA is clear. In addition, 
instructions are provided to set or test the value of the CBA 
and CBB fields. 



4.4.2.11 CC ~ Condition Code 



The condition code field in the STATUSB register reflects the 
result of the most recent test or compare operation. 
The four values of CC are indicated in this document mostly 
through mnemonics (CCG,CCE,CCL,CCU) as follows: 

stands for: 






CCG 


1 


CCL 


2 


CCE 


3 


ecu 



condition code "greater" 
condition code "less" 
condition code "equal" 
condition code "unordered" 



On a Compare instruction, CC is given the value "CCG" if the 
first operand is greater than the second operand. Uith a Test 
instruction, CC is given the value "CCG" if the first (only) 
operand is greater than zero. Similarly for CCL amd CCE. 
CC is given the value CCU only on floating point compeure or 
floating point test when the two values being compared are 
"unordered" with respect to each other according to the IEEE 
floating point standard. 
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Some instructions other than Tests and Compares cause CC to get 
set. These instructions are eKplicitly designated in chapter 6. 
All other instructions leave the condition code field unaltered. 



4.4.3 STATUSC ~ CPU Status 



4.4.3.1 Format 




STATUSCl 



DDC 



2 2 2 3 3 
7 8 9 1 
— + — + + + — + 

iXMllCSlDRFlIEl 
._+ — + + + — + 



1 1 
5 6 



STATUSC2 



IMR 



4.4.3.2 Summary 
Field name 



Uord Bit Positions 



CI 


0-27 


CI 


28 


CI 


29 


CI 


30 


CI 


31 


C2 


16-31 



DDC — Dispatcher Disable Count 
XM — Execution Mode 
ICS — On Interrupt Control Stack 
DRF — Dispatcher Request Flag 
IE — Interrupt Enable/Disable 
IMR ~ Interrupt Mask Register 



4.4.3.3 DDC — Dispatcher Disable Count 



The value of DDC is incremented by the PSDB instruction and 
decremented by the PSEB instruction. The function of DDC is to 
monitor when it is appropriate to enter the dispatcher. As long 
as DDC is non-zero, the dispatcher is not permitted to run. 
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4.4.3.4 XM 



Excecution Ifode 



XM defines the current mode of execution. Uhen XM has the value 
zero, hardware executes in Vision mode. Uhen XM has the value 
one, hardware executes in HP3000 mode. The value of XM changes 
as a consequence of executing any of the veiriants of SWITCH. 
Also, any transfer of control to the Interrupt Control Stack 
from HP3000 mode will cause XM to be zero. 



4.4.3.5 ICS — On the Interrupt Control Stack 



This flag is set to one when execution switches to the Interrupt 
Control Stack, e.g. on an external interrupt. This flag is 
cleared on an lEXIT that returns control to a task. 



4,4.3.6 DRF ~ Dispatcher Request Flag 



This flag is set to one by the DISP instruction if access to 
the dispatcher is temporarily deferred. In order to enter the 
dispatcher, the following conditions must be simultaneously 
satisfied: 

a) STATUSC. DDC = 

b) STATUSC. XM = 

c) STATUSC. ICS = 

d) STATUSC. IE = 1 

Uhen DRF is one, any action that causes either condition (a) 
or (b) or (c) or (d) to become satisfied will reexamine all 
four conditions; if all four are now found satisfied, the 
dispatcher will be entered. 



4.4.3.7 IE & IMR ~ Interrupt Enable/Disable & Mask Register 



The IMR field determines which external interrupts are allowed 
to alter the flow of control. If IE=0, no interrupts can alter 
flow of control, overriding the value of IMR. See section 7.2 
for more detail. 
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4.4.4 STATUSD ~ Computer Status 
4.4.4,1 Format 



12 3 

+-+ — + 

STATUSD I IDRLI REVCODE 
+-+ + 



31 



4.4.4.2 Summary 



Field name Bit positions 



DRL ~ Debug Ring Level 1-2 
REVCODE — SPU Revision code 3-31 



4.4.4.3 DRL ~ Debug Ring Level 



This field defines which eKecution ring levels are subjected to 
the debug breakrange traps. Specifically, the System Breakrange 
trap and the Task Breakrange trap as well as the procedure trace 
trap are enabled only at ring level DRL and less privileged 
rings. Typically, DRL equals 1 in order to allow I/O to proceed 
at full speed even while debugging at all other privilege levels. 
However, highest privilege code can be debugged too, by setting 
DRL to zero. 



4.4.4.4 REVCODE ~ SPU Revision Code 



This is a unique number assigned at the factory for each SPU or 
version of an SPU which differs significantly from a prior 
version. The most significant 13 bits are unique for each SPU; 
bits 16-31 identify each significant revision of the SPU. 
This is NOT a serial number: it is not unique for each unit. 
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4.5 Group Descriptors 



Address translation of logical addresses to virtual addresses 
requires the hardware to be able to locate the eight Object 
Descriptor Tables. Eight Group Descriptors (GD) serve to locate 
these ODTs. The Group Descriptor for group zero is kept in a 
processor register; it can be thought of as an extension of the 
STATUSD register. The Group Descriptors for groups one through 
seven exist in the Task Control Block (TCB) of the currently 
executing task. All eight Group Descriptors have the same 
format, which is described below. The TCB is located by 
hardware through the TCB.VA virtual address; TCB.VA is kept in 
a processor register that can be considered as an extension of 
STATUSC. The format of the TCB is described in section 4.7. 



I I i 

LON I I I 

012 3 31 I I I 

+ — + + v + + \ 

I I LON~logical object number] I////I I 

+ — + + + + I 

I VON — virtual object number I <===> |VON I | 

GD: + + + + > OD 

I LB ~ lower bound I <===> I LB I I 

+ + + + I 

I UB ~ upper bound I <===> |UB I I 

+ + + + / 

I I 
I I 
II 

+ + 

ODTO 



The last three words of the Group Descriptor contain the Virtual 
Range that locates the ODT in virtual space. The first word of 
the Group Descriptor contains the Logical Object Id of an object 
in Group 0. This LOI exists for the purpose of allowing certain 
hardware TLB organizations. 

Operating system software must ensure that the Virtual Range 
contained in the OD identified by LOI is identical to the virtual 
range contained explicitly in the GD. 
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4.6 Virtual address translation registers 



Hardware must be able to locate the Hash table and the Page 
Directory in physical memory; this is necessary for being able 
to do virtual to physical address translation. 
Two processor registers serve this purpose; they can be thought 
of as an extension of STATUSD. 



HASH. PA 



PDIR.PA 



HASH. PA contains the physical address of the Hash table; this 
address must be page aligned. 

PDIR.PA contains the physical address of the Page Directory 
PDIR; this address must be aligned on a 16-byte boundary. 



(physical 


page number 


of Hash 


1 0000000000001 









27 28 31 


1 page 


directory 


locator 


looooi 
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4.7 Task Control Block 



Hardware needs a certain amount of information in order to 
execute the current task. This information is stored in the 
Task Control Block (TCB), located by a register TCB.VA. 
This TCB.VA register can be thought of as an extension of 
STATUSC. TCB.VA must be a multiple of 16. The length of the 
TCB is 176 bytes. Also, the TCB must be memory resident. 

A 64-bit register TCB. LA accompanies TCB.VA; operating system 
software is responsible for ensuring that the logical address 
TCB. LA does in fact translate into the virtual address TCB.VA. 
Moreover, the logical address TCB. LA must have a zero group 
selector. Hardware implementations are free to use either 
TCB. LA or TCB.VA to locate the TCB. 

A task switch is accomplished by Dispatcher software through 
simultaneously changing the TCB.VA and TCB. LA registers. 



12 

/TCB. LA +— + +— 

\TCB.VA 



31 



==> 

+4 


IXMISUIPI reserved I 

+— + + for + 

1 hcirdweure 1 


+8 
+ 12 


1 TCBX 
1 


.LA — logical addrl 
of TCB extension I 


+16 
+20 
+24 
+28 


1 

1 GDI 

1 
1 


1 

~ group descriptor! 

for group 1 1 

1 


+32 
+108 


1 

i 


1 

i 


+112 
+116 
+120 
+124 


1 

1 GD7 

1 
1 


1 

~ group descriptor! 

for group 7 j 

! 


+128 
+ 132 
+ 136 
+ 140 


1 1 
1 Task Breakrange I 
1 Descriptor 1 
1 1 



+ 144 
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I I 

^ ^ \ 

TCB.VA +144 I SO - HP3000 node I I 

+148 I Stack Pointer I I 

+ + > HP3000 mode 

+152 I CSTX I I information 

+156 I descriptor 11 

^ ^ / 

+160 I SN - Vision mode I \ 

+164 I Stack Pointer | I 

^ , I 

+168 I logobjid of VCSA I > Vision mode 

+ + I information 

+172 I TEYOFFSET | | 

+ + / 

+176 I I 



XM — execution mode of the task. On lEXIT to this task, 
execution mode STATUSA.XM is set to this value, 

SUIP — switch in progress. This bit is used by I EXIT when a 
mode switch could not be completed, 

TCBX,LA- The logical address of a TCB extension for use by 
software, 

GDi — Group Descriptors, The format of a Group Descriptor is 
described in section 4,5, 

Task Breakrange Descriptor, 

This descriptor is described in section 4,9. 



SO 



Logical address of top-of-stack of the HP3000 mode 
stack used to initialize S on lEXIT, 



CSTX Descriptor, 

The descriptor locates the CSTX used in HP3000 mode. 
Its format is the same as described in section 4,10, 

SN — Logical address of top-of-stack of the Vision mode 
stack used to initialize S on lEXIT, 

logobjid of VCSA. 

The logical object id of the logical object in use as 
the Vector Context Save Area. See section 4.11. 

TRYOFFSET. 

The stack offset saved by the TRY instruction. 
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4.8 Breakranges (System and Task) 



The VISION architecture supports two breakranges: a System 
Breakrange and a Task Breakreuige. A breakranges involves a 
range of virtual addresses. Uhen properly enabled, the 
breakrange will cause a trap to occur at the completion of any 
instruction that overwrites any byte within the breakrange. 
This debug aid is discussed in more detail in section 5,3. 

The Descriptor for the System Breakrange can be thought of as an 
extension of STATUSD: once installed and properly enabled, the 
System Breakrange will cause a trap whenever any task on any 
processor in a shared-memory multi-processor writes to any byte 
within that Breakrange. The Task Breakrange Descriptor can be 
thought of eis an extension of STATUSB; it is located in the Task 
Control Block. Uhen properly enabled, the Task Breakrange will 
cause a trap when this particular task writes to any byte within 
this Breakremge. 

A Breakrange Descriptor is a 16-byte descriptor with the format 
shown below. 



Breakrange 
Descriptor: 



reserved for hardware I 

+ 

VON - virtual object nr | 



I LB - lower bound 

+ 

I UB - upper bound 



4.9 Interrupt Control Stack location 



The Interrupt Control Stack (ICS) is the environment in which 
hardware interrupt handlers run. Several trap handlers also 
run on the ICS. This environment is described more fully in 
section 7.6. 

The ICS is a logical object in group 0. Uhen an interrupt is 
acknowledged, Q is made to point to a location on the ICS just 
beyond the Dispatcher Marker (see 7.2). This location is 
called QI . The logical suSdress of QI is kept in a processor 
register that can be thought of as an extension of SIATUSC, 
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4.10 CST and DST descriptors 



HP3000 mode requires a Code Segment Table (CST) as mell as a 
Data Segment Table (DST) to complete its addressing environment. 
Both CST and DST are tables of ODs. These tables are actually 
contained within the ODT for group zero. Both CST and DST are 
found through processor registers containing 64-bit descriptors 
as indicated below: 



012 3 31 

^___^ ^ \ 

I I object number where CST/DST starts I I 

+ + + > CST or DST 

I length of CST/DSr in bytes I | Descriptor 

^ + / 



index 



I length 

h 

CST or DST 
descriptor 



\ 

I 

I CST 

> or 

I DST 

I 

/ 



ODTO 
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4.11 Vector Processing 



VISION offers rich support for vector operations in order to 
significantly increase performance on common array and matrix 
operations in technical applications. 
This section should be read in conjunction with section 6.4. 



4.11.1 Vector Registers 



A task can address 8 vector registers VRO, VRl,.., VR7. Each 
VR consists of N elements, numbered through N-1, where N is 
an implementation-dependent quantity no greater than 256. 
Each element is 128 bits wide, and can contain values of data 
types comprising 32, 64 or 128 bits. 

Not all N elements in a Vector Register need be filled with 
data; software may load vectors with fewer elements into a VR. 

Vector processing hardware may support up to 15 banks of eight 
vector registers each. Only one bank is addressable by a task 
at any time. Multiple banks allow multiprogramming of tasks 
using vector registers without excessive performance penalty 
in saving vector register contents on a task switch. 



4.11.2 Vector Mask Registers 



A task can address 4 vector mask registers, VMRO, . ,,VMR3. Each 
contains 256 bits. A bit in a vector mask register corresponds 
to an element in a vector register. 

Each vector instruction designates a vector mask register to 
govern execution of that instruction. Elements in the vector 
register corresponding to clear bits in the mask register do not 
participate in the vector instruction; no results are stored in 
the vector register element, the original value of the element 
does not change, and under no circumstance can traps occur for 
that element. 

The values in the mask registers can be created and manipulated 
through special instructions including vector compare. 
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4.11.3 Vector Length Register 



Various means exist for software to let hardware know how many 
elements in a vector register should be regarded as meaningful 
and how many elements should be operated on in a given vectot 
instruction. 



4.11.4 Vector Context Save Area 



Because vector registers contain a large amount of information, 
it is not desireable to save all this state on an external 
interrupt. Interrupt handlers must therefore refrain from using 
vector instructions. 

Vector Registers (and vector mask registers) are saved either 
explicitly by operating system software or automatically when 
another task executes a vector instruction that uses the same 
vector register bank. Uhen vector registers are saved, they 
are saved on behalf of the task that last used them. Part of 
the task's context includes the Vector Context Save Area (VCSA), 
located through the task's TCB, memory resident, and large 
enough to receive all vector register values. 



4.11.5 Vector Processing: Operation 



Operating system software may allow any task or any number of 
tasks to execute vector instructions. VISION implementations 
may have special purpose hairdware, referred to as a Vector 
Processor (VP), which will improve the performance of the 
vector operations. 

The VP will contain some amount of memory, organized as one or 
more banks. A bank generally contains all of one task's vector 
related context, including vector registers, vector mask 
registers, vector length register, etc. This context is quite 
laurge, and requires attention in order to maintain fast 
interrupt response, ability to multiprogram, and minimal impaict 
on pure scalar tasks. 

A task must be assigned a special region of main memory called 
the Vector Context Save Area (VCSA) before it can execute any 
vector instructions. Additionally, a task must be assigned a 
bank in order to use the VP. A task may be denied access to 
the VP, in which case all of its vector activity occurs through 
its VCSA; this limits the speed of vector instructions to the 
speed of memory access. 
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More than one task may be assigned the same bank. If this occurs, 
hardware is responsible for saving/restoring the context when a 
vector task enters execution and a different task's context is 
in the first task's assigned bank. The hardware will save the 
first task's vector context into its VCSA, and reload the bemk 
from the new task's VCSA. 

Note that if a task which does not use the VP (a scalar task) 
starts to run, the interrupted vector task's VP context will be 
protected but remain in the hardware registers. If control 
returns to the same vector task, the VP context switch will have 
been avoided entirely. If control returns to a different vector 
task which has been assigned the same bank, the context switch 
will occur when the new vector task attempts to execute its 
first vector instruction. 

The vector processor may contain to 15 banks of context. The 
operating system will designate which bank (if any) a task is 
allowed to use. A group of tasks assigned the same bank will 
only compete among themselves for that VP context. 



4.11.6 VP Management - Vector Context Save Area 



Use of the vector processor by a task is controlled by six bits 
in STATUSB, altered only by operating system software. Four of 
these bits specify the bank number, and two specify permission 
level. 

If the bank number is not 0, the number specifies which harduaure 
bank of VP context is to be used by this task. 

If the bank number is 0, all vector activity takes place through 
the VCSA instead of the vector registers. The hardwaire context 
consumed is effectively zero, but all operand/result (including 
VR) accesses proceed at memory speeds. The performance in this 
mode will be degraded, but will normally be faster than equivalent 
scalar code. Through this feature operating system software can 
allow a low priority vector task to execute, while reserving 
the vector hardware for some very important task. 

The permission bits must be made non-zero by operating system 
software if a task is to be allowed use of the vector processor. 
Before operating system software grants permission, a portion of 
the VCSA must be locked into memory. This is to: 

a) prevent phantom page faults, 

b) ensure that a pleice exists in which to save context should 
power fail, 

c) provide a place to simulate VRs should the implemented hardware 
be insufficient. 
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Note that the VCSA is sketched assuming 128 element VRs. 
The State Information in Part A is detailed below: 

State Information 


Permission I Meaning 
bits value | 


1 VMR0..VMR3 | 


128 1 VLR 1 


00 1 No VP use allowed by this task. 

01 1 VP usage restricted to vector data types 

1 <= 32 bits; hardwaire assumes that parts 
1 A & B of the VCSA are locked into 
1 memory. 

10 1 VP usage restricted to <= 64 bits of vector 
1 data; hardware assumes that parts A, B 

1 & C of the VCSA are locked into memory. 

11 1 VP usage unrestricted; hairduare assumes 

1 the entire VCSA is locked into memory. 

If insufficient permission has been granted when the task attempts 
to execute a vector processing instruction, the INSVPPERM trap 
occurs. Operating system software will typically lock in the 
additional portion of the VCSA and then redispatch the task. 

If the permission bits are not 0, the VCSA logical object id 
in the TCB identifies the VCSA for that task. The entire VCSA 
is a 1/4 + 8*(VR Ien*4/1024) page area. (For 128-element VRs, 
this is 4 1/4 pages. ) Conceptually, the contents of the VCSA 
at the time of an interrupt are as sketched below. 

Vector Context Save Area 


132 1 VR descriptors 1 


148 1 information 1 
1 on partially I 
1 completed 1 
: vector : 
1 operation I 


1024 1 1 

Only the portion of a VR save area corresponding to the VR's 
active length is meaningful. Bytes 0-127 of State Information 
contain the VMRs as they exist at the time of interrupt or 
task switch; bytes 128-131 contain the VLR. Bytes 132-147 
describe the width and active length of each VR. 

A vector instruction may be interrupted before it is complete. 
In this case, information sufficient to transparently resume the 
partially completed operation is stored in bytes 148-1023 of the 
State Information area. 

As explained above, when an interrupt occurs the VCSA is not 
immediately updated. Two instructions are available to force 
immediate updating of the VCSA. The first is UVCSA (Update 
Vector Context Save Area) . This is a non-privileged instruction, 
aind contains a two-bit option field to force saving of either 
VRs, State Information, or both. UVCSA may be used by a trap 
handler to isolate the elements and operation causing the 
vector trap. The second instruction, PUVCSA (Privileged Update 
of Vector Context Save Area) allows specification of the vector 
bank to be saved, independent of the vector bank in use by the 
current task. Operating system software may issue this 
instruction if it is waiting to transfer control to a vector 
task and wishes to minimize that task's startup time. 


1 Part A 1 
1 State Information | 


10241 Part B 1 
1 First 32 bits of each 1 
1 element of VR0..VR7 | 


51201 Part C I 
1 Second 32 bits of each I 
1 element of VR0..VR7 | 


92151 Part D 1 
1 Last 64 bits of each | 
1 element of VR0..VR7 I 


17408 1 1 
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current stack object 




1 1 1 




1 MACHINE MODEL 1 CHAPTER 5 | 
1 II 


SB ==> 1 1 
1 1 
1 storage for I 




"*"""" —— — ———— — ——— — ! — — — — — ^— — — — — — — — — — — — — — — — ^ 






1 variables and 1 






1 temporaries I 




This chapter discusses several topics relevant to the operation 


1 for 1 




of Vision node brought together under the heading "machine model" 


1 outer blocks | 




because they contribute to a more coherent picture of the model 


1 of programs 1 




than might be gleaned from the detailed description of individual 


1 1 




instructions in chapter 6. 


1 1 




These topics are: 


Q ==> 1 1 
1 1 


a) stack and stack markers 


1 1 
1 local storage I 




b) procedure linkage 


1 for 1 




c) debug support 


1 currently | 




d) list of supported data types 


1 active I 
1 procedure I 
1 1 




5.1 The Vision Stack 


1 1 




S ==> 1 1 




The Vision mode stack is primarily used for procedure linkage, 


1 1 
1 the values in 1 




parameter passing and allocation of local and temporary variables 


1 this area are I 




for procedures, to the extent that the registers X0..X15 do not 


1 indeterminate 1 




suffice for this. The stack is also used as an implied place to 


1 1 




store things, such as parameters when traps are taken or when 
internal and external interrupts occur. 


1 1 




^— ————— ————— ————.— ————— —^ 




The registers Q and S always point to the stack. The ujjper 32 


SL ==> 1 




bits of Q and S are identical; they identify the current stack 






object. Refer to section 2.3.6. 






The stack is totally uord-oriented: the stack object is word- 


The logical address corresponding to the first byte in the stack 




aligned in virtual address space, and the logical addresses Q 


object is denoted by SB; similarly, SL denotes the first byte 




and S are both at all times multiples of four. The length of 


beyond the stack object. The following relationship among these 




the stack object is a multiple of four as well. 


registers is always gueiranteed: 




S points to what is called top of stack. Q points to what is 


SB <= Q <" S <= SL 




called the local stackframe. 






S changes under the effect of explicit PUSH and POP instructions 


The necessary checks to guarantee this are performed when S or Q 




and their variants (e.g. DUP, EXTEND, DELETE), and implicitly 


change. The area between S and SL is indeterminate. This means 




on traps and interrupts. 


that its contents cannot be predicted. Stack bounds checking is 




Q changes only on procedure calls (CALL, CALLX) , on procedure 


more restrictive than bounds checking on ordinary objects. All 




returns (EXIT), through a MOVEtSP, and implicitly on traps. 


memory accesses through logical addresses with an LOI equal to 
that of current Q are checked against S as the upper bound rather 
than against SL. The EXTEND instruction will increase S without 
explicitly initializing the area between the previous S and the 
new S; the newly accessible part of the stack will have contents 
that are unpredictable. 
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5.1.1 Procedure Stack Marker 



The procedure stack marker is a 3 * 32 bit entity that is pushed 
on the stack as part of procedure call (CALL, CALLX); at this 
time a new stack frame is created by setting Q to point to the 
area in the stack immediately beyond the marker. The marker 
preserves the information necessary for EXIT to restore the old 
environment, specifically, the old value of Q. 



5.1.1.1 External Procedure Stack Marker 

External procedure calls (CALLX) push a 3-Mord marker as shown: 

Sold==>| I 

Q-12 I P[0..31] I 
+ + + 

Q-8 ISTATUSAl P[40..63] I 
+ + + 

Q-4 I Qold[32..63] | 
Q=Qnetii=Snew==>| I 



The value of P in the marker is the logical address of the 
instruction follouing the CALLX. The size of code objects is 
restricted to 2**24 bytes so that P[32..39] = 0. 
The value of STATUSA contains the privilege level at which the 
caller ran. STATUSA[0] = 1. Bits STATUSA[1. ,7] mill always be 
clear when executing CALLX. 

Traps and external interrupts also push an external procedure 
marker. Here the value of P in the marker is the logical 
address of the instruction that needs to be executed after 
returning from the handler. The IIP bit and the DBP bit in 
STATUSA may be set. 

An SIT value of one must never be pushed as part of STATUSA in 
the external procedure marker. Instead, it may only be set in 
the marker explicitly by software. Such software will use EXIT 
to cause the SIT flag to get set in the calling program. 
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5.1.1.2 Local Procedure Marker 



The local procedure call (CALL) never causes the execution level 
to change, nor can it change the current code object. The stack 
marker for a local call can therefore be simpler than for an 
external procedure call: 



Q-12 I hardware reserved I 

+ + 

Q-8 I P[32..63] I 

+ + 

Q-4 I Qo Id [32.. 63] | 

Q=Qnew=Snew==>| I 



Note that EXIT can unambiguously distinguish between a local 
procedure marker and an external procedure msirker: (Q-8) [0] 
has the value for a local marker and the value 1 for an 
external marker. The bits P[32..39] are zero. 
Note that both markers occupy the same amount of space. 



5.1.2 Interrupt Marker 



An interrupt marker is pushed on the stack as part of servicing 
(acknowledging) an interrupt (external or internal), or when a 
task transfers control to the dispatcher (with the DISP, PSEB or 
ENABLE instruction) , or upon executing SUITCH. 
The marker contains the following information (see lEXIT): 



1. the information in an external procedure marker 

2. STATUSB 

3. general registers X0-X15 

4. base registers B0-B5 
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S_old ==> I I 

Q-12 I P I 

+ + + 

Q-8 ISTATUSAl | 
+ + 

Q-4 I Gold [32,. 63] I 
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Q ===> I (B1)I 

+- STATUSB -+ 

Q+4 I (B2)| 



Q+8 



XO 



Q+68 
Q+72 
Q+76 



X15 



BO 



Q+112 

Q+116 

S = = => 
(0+120) 



B5 
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5.1.3 Dispatcher Marker 



The Dispatcher is a piece of operating system software that 
selects the next task to run, in preparation for a task switch. 
The dispatcher is entered automatically under certain conditions 
carefully controlled by the DISP, PSDB, PSEB, ENABLE and DISABLE 
instructions. The dispatcher code is entered through a special 
procedure marker called the Dispatcher Marker, which is at the 
base of each Interrupt Control Stack (ICS), This marker is 
never removed, in contrast to all other stack markers. Entering 
the Dispatcher is similar but not identical to an EXIT through 
the Dispatcher Marker: Q will not change, S will get set to Q. 



The Dispatcher Marker contains: 



1. Program counter for entry point of Dispatcher 

2. STATUSA 



QI-12 I P (entry point I 
+ + of + 

QI-8 ISTATUSAl dispatcher) | 
+ + + 

QI-4 I Qold[32..63]=QI[32..63]| 

QI ==> I I 



Just before the Dispatcher starts running, the lEXIT instruction 
will initialize STATUSB to the value DispatcherStatusBInit, 
which has the following fields: 



Field 



Value 



DISP 


= 1 


PTE 


= 


vector 


= 


XTL 


= 3 


FPC 


= 


TE 


= 


EF 


= 


CBA 


= 


CBB 


= 


CC 


= 



Full name of field 

Dispatcher running flag 

Procedure Trace Enable 

vector control 

EXIT threshold level 

IEEE floating point control 

Trap Enables (none enabled) 

Exception Flags (none detected) 

Conditional Break Enable, A 

Conditional Break Enable, B 

Condition Code 
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5.2 Procedure Linkage 



The Vision instruction set provides several forms of procedure 
call. Their detailed description is given in chapter 6. 
The instructions CALL and CALLX both create a new staickframe by 
pushing a procedure marker and then updating Q and S. CALL and 
CALLX differ primarily in the way they arrive at the target 
address. This is detailed in section 5.2.1. They also lay down 
a different marker because EXIT must be able to return to the 
appropriate environment in each case. 

A procedure must be wholly contained in a code object; it cannot 
span several code objects. Conversely, a code object may have 
many procedures in it. Procedures within the same code object 
may call each other using the CALL instruction; this is the 
fastest procedure call. Code objects are paged, their maximtjm 
size is 2^24 bytes; hence there is opportunity to group large 
numbers of procedures into a single code object. The following 
reasons may limit in practice the number of procedures that are 
combined into a single code object: 

a) procedures in a code object run at the same privilege 

b) if a procedure in a code object is recompiled, all of 
the code object must typically be relinked 

c) the procedures in a code object eire not protected from 
one another; a procedure may jump in the middle of 
another procedure without being caught 

d) often-used procedures can be put in a separate code 
object and shared among many user programs; this trades 
off space and link time versus CALLX overhead 

Code objects can have multiple external entry points; however, 
this requires the approach outlined in section 5.2.2. 



5.2.1 Entry Point Evaluation 



The external procedure call CALLX has as its single operand the 
logical object id (LOI) of the target code object. This LOI is 
sufficient to determine the location of the target procedure. 
The LOI uniquely identifies an Object Descriptor (OD) which has 
the format described in section 2.3.2. The first word of this 
OD is included on the next page. 
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01 23 45 6 7 8 

(. — + — + +_+ — 

|XL|RL|TYPE|0| 

K + + + _+ 



2 33 
9 01 



EPUO 



IPRI 



first word of 
OD of target 
of CALLX LOI 



where: 
TYP 
PR 

XL 
RL 



- should indicate a Vision mode code object 

- indicates the prerequisite level: the privilege level 
the caller must already possess before being allowed 
to complete the procedure linkage 

- indicates the privilege level at which the tairget 
procedure will run 

- indicates the privilege level required for reading 
the contents of the code object as data 



EPUO - the entry point word offset: indicates the location 
of the starting point of the target procedure, 
expressed as a word offset relative to the start of 
the code object 



The new program counter P is constructed from this information 
as follows: 



3 3 
1 2 



3 4 
9 



6 66 
1 23 



LOI 



EPUO 



1 001 



5.2.2 Multiple Entry Points in a Code Object 



It is possible to have multiple external entry points per code 
object, but only by duplicating Object Descriptors. This means 
that each external entry point must be associated with a unique 
logical object id. This is not the same as stating that each 
external entry point corresponds to a single code object, for 
these Object Descriptors will share the identical Virtual Range 
contained in their last three words. These procedures can still 
call each other freely using CALL instead of CALLX, thus keeping 
all characteristics of being in a single code object. 

5-8 



VISION ARCHITECTURE CONTROL DOCUMENT 
DO NOT COPY ~ HP PRIVATE INFORMATION 



07/31 



5.3 Debug Support 



The VISION architecture is rich in features to support debug of 
software. This section collects these features in one place; 
however, pervasive object bounds checking has already been 
covered in chapter 3 as has checking of access rights. 



5.3.1 Code Breakpoints 



The following instructions are provided and can be inserted into 
the code stream either at compile time or at run time: 

a) BREAK 

b) CHECKA 

c) CHECKB 

Each is capable of generating a trap: BREAK unconditionally, 
CHECKA and CHECKB conditionally on the setting of an appropriate 
bit in STATUSB (STATUSB.CBA and STATUSB.CBB respectively). 
Debug software can use these instructions to provide code 
breakpoints, code tracing, etc. 



5.3.2 Breakranges 



The VISION architecture provides two Breakranges that can be 
used to protect an area from accidental or malicious writes and 
to trap any software that changes any data anywhere within the 
Breakrange. The format of these Breakranges is discussed in 
section 4.8, 

The System Breakrange is a Virtual Range kept in a processor 
register and set by a MOVEtSP instruction. Any write within the 
Virtual Range causes a breakrange trap when properly enabled. 
The Task Breakrange is a Virtual Range kept in the Task Control 
Block. Any write by that task within the Virtual Range causes a 
breakrange trap when properly enabled. 

Two ways exist to disable the breakranges and totally eliminate 
their performance impact: 

a) setting the DRL field in STATUSD to a non-zero privilege 
level. This will disable the breakrange for all code at 
level DRL or more privileged. 

b) clearing the "DBE" bit in the PDIR for a particular VPN. 
Only accesses to pages with the DBE bit set are checked 
for breakrange traps. 
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The VISION architecture does not require hardware to run at 
"normal" speed when accessing an enabled page at an enabled 
privilege level. Softwaure should suiticipate some performamce 
degradation in this situation. 



5.3.3 Single Instruction Trace 



Software can cause hardware to sequence through user code a 
single instruction at a time. This is accomplished through the 
SIT bit in STATUSA. The only way to set this bit is to modify 
an external procedure marker and then execute EXIT (or lEXIT). 
EXIT will restore STATUSA with the SIT bit set. This will not 
have any effect until the next instruction has completed. Any 
instruction that has SIT set at its beginning will on completion 
transfer control to the DBSIT trap handler. As part of the trap 
initiation, SIT will be cleared. In order to determine whether 
to take the DBSIT trap, hardware only needs to check the SIT bit 
at the completion of an instruction, provided it delays setting 
the SIT bit in an external EXIT so as to avoid trapping out on 
the EXIT instruction itself. 



5.3.4 Procedure Trace 



If the PTE bit in STATUSB is set and the current privilege level 
XL is numerically greater (less privileged) thcin DRL, any 
execution of CALL, CALLX or BRX will cause the restartable trap 
DBCALL to be taken. 



5.3.5 Object Treice 



In the VISION architecture, an access rights violation causes a 
restartable trap, of. chapter 7. This trap can be fashioned by 
software into an object trace capability. Operating system 
software can manipulate the access rights in the OD of an object 
such as to cause access rights violations when code attempts to 
access the object with current privilege level XL numerically 
greater than DRL. Since this trap is recoverable, execution 
can resume normally after the debugger has restored the original 
access rights. The Single Instruction Trace mechanism can be 
used to regain control at the completion of the instruction in 
order to reinstate the object trace. 
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5.3.6 Ring Crossing Trap 



This trap is detailed in chapter 6 under EXIT. The STATUSB.XTL 
(exit threshold level) field can be set to a certain privilege 
level under operating software control. This allows delaying a 
certain activity until the task has exited back to sufficiently 
low privilege on its own accord. Any EXIT (or lEXIT) that drops 
the current privilege level below (numerically greater) than XTL 
will cause the Ring Crossing Trap to be taken. 



5.4 List of Supported Data Types 



Vision mode software supports various data types. Some are 
supported through a full complement of instructions, some are 
represented by a few key instructions and/or conversions into 
fully supported data types. A brief summary follows: 







data types 




# bytes 


integer 


floating 


decimal 


1 


1 


_ 


- 


2 


2 


- 


- 


4 


4 


4F 


4D 


8 


8 


8F 


8D 


16 


- 


16F 


16D 



5.4.1 Integers 



Vision mode supports both 32-bit two's complement integers and 
64-bit two's complement integers with full arithmetic capability 
including shifts. 

16-Bit 2's complement integers are supported through conversion 
to and from 32-bit integers and by fast detection of 16-bit 
overflow on 32-bit arithmetic. These conversions are done 
automatically on loading a 16-bit integer into a 32-bit register 
or storing a 32-bit register into a 16-bit memory location. 
8-Bit unsigned integers are supported through conversion to and 
from 32-bit integers. The conversion is implied in loads and 
stores to and from 32-bit registers. 

5-11 



VISION ARCHITECTURE CONTROL DOCUMENT 
DO NOT COPY ~ HP PRIVATE INFORMATION 



07/31 



5.4.2 Floating Point 



Vision mode performs floating point operations exactly as 
described in the IEEE floating point standard ("A Proposed 
Standard for Binary Floating Point Arithmetic", IEEE Task P754). 

The standard allows some features to be defined by implementors. 
These options are defined for Vision mode as follows: 

Formats: The formats supported are Single, Double, Quad. These 
occupy 32 bits, 64 bits and 128 bits, respectively. 
Quad is defined in the manner provided for "Double 
Extended" by the Standaird. 

The 32-bit single precision floating point format has 
a 1-bit sign, an 8-bit biased exponent and a 23-bit 
fraction field. 

The 64-bit double precision floating point format has 
a 1-bit sign, an 11-bit biased exponent and a 52-bit 
fraction field. 

The 128-bit quad precision floating point format has 
a 1-bit sign, a 15-bit biased exponent a 1-bit integer 
part and a 111-bit fraction field. 



Modes: Normalizing mode is provided. All five traps aure 
supported, with individual enable/disable. 

Underflow: 

Underflow is always checked after rounding. 

Operations: 

Add, subtract, multiply, divide and conversions 
between all data types are fully supported by Vision 
instructions. Remainder, square root, integer ize, 
as well as binary ~ decimal conversions must be 
supported in software. 



5.4.3 Decimal 



Vision supports packed decimal data types of size 4,8 and 16 
bytes. These formats are described in detail in chapter 6.3. 
Vision also supports conversion to and from packed decimal 
data of any number of bytes between 1 and 31. External numeric 
decimal formats are supported through conversion to and from 
packed decimal. 
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5.4.4 Logical 



Various bit-wise operations are supported on 32-bit quantities. 
The most significant bit and the least significant bit of a word 
can be tested individually. 



5.4.5 Bit 



Instructions to set bits and test bits in arbitrary locations in 
an object are provided. 



5,4.6 Fields 



An instruction to deposit a value of an arbitrary number of bits 
into a 32-bit word is provided. 



5.4.7 Byte strings 

Various instructions to support operations on strings of bytes 
are provided: move, compare, translate, translate and test. 
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VISION INSTRUCTION SET 



I 

I CHAPTER 6 

I 



This chapter describes the instruction set available in Vision 
mode to the programmer Mho needs to write software in assembly 
language. Vision compilers will compile stamdard programming 
languages to this instruction set. 



6.1 Preliminaries 



The register P (program counter) contains a 64-bit logical 
address that points to a variable length entity called an 
instruction . The instruction is interpreted by hardware and 
executed; this changes the machine state and/or memory. 
The program counter P is among the machine state that changes 
as a consequence of instruction execution; the default is to 
advance (increment) P to point to the next instruction in 
sequence . 



I D2 I 02 I 91 I 98 I D4 I 



X3 



13 



In the sketch above, the pattern 1D2029198 is the encoding of 
a 32-bit instruction that will be rendered here as: 

ADD4 2, X3 

This instruction instructs the hardware to perform a 4-byte ADD 
(32-bit integer addition) on 2 and X3, leaving the result in X3. 
After executing this instruction, clianges will have occurred 
to X3, to P and to the reference bit "R" in the physical page 
descriptor for the page containing the instruction. No other 
machine state nor memory will be affected. In this example, 
the value of X3 will have been incremented by 2; the value of 
P will have been incremented by 4 (to skip over the current 
instruction which occupied 4 bytes). 
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The situation after executing the "ADD4" instruction will hence 
be as follows: 



D2 I 02 I 91 I 98 I 04 

+ +- + + 

P 



X3 



15 



The Architecture Control Document does not describe how this 

effect on the machine state is achieved; different hardware 

implementations may use quite different means. 

In this chapter only the intended effect of an insti^iction on 

the machine state and/or memory is given, in a mixture of 

running text and a Pascal- like algorithm. 

Several aspects of instruction execution are so pervasive that 

they will be described once rather than repeatedly for each 

instruction. 

The most important of these is the way operands are dealt with. 

Operands are described in section 6.1.1 and their encoding is 

dealt with in sections 6.1.2 and 6.1.3. 

Other such pervasive actions are: 

incrementing the program counter at the end of executing 

an instruction 
fielding external interrupts at the end of executing 

an instruction 
detecting page fault on fetching the instruction 
detecting page fault on fetching operands 
setting dirty amd reference bits as part of accessing 

memory 
serving debug traps at the end of an instruction that 

write into a breakrange; 
checking access rights/bounds violation on any memory 

access 
trapping on a mismatch of operand and operaind attribute 



Several of these pervasive actions involve reporting unusual 
or illegal conditions; refer to section 6.1.8 for more detail. 
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6.1.1 Operands 



In the previous example, "ADD4 2, X3" is an instruction with 
two operands. The first operand, "2" is called a literal , or 
a literal operand. This means that the value of the operand 
can be found right there in the instruction itself. 
The second operand, "X3" is called a register operand . The 
value of this operand is the value currently m the X3 register. 
The operation called for by the instruction, "ADD4", is an 
addition; this involves storing the result somewhere. The 
description for "ADD4" specifies that the result be stored back 
into the second operand. This means that X3 is not only used 
to obtain one of the values to be added together, X3 is also 
designated as the destination for the result. 
Note that a register can be a destination for a result, but a 
literal cannot: the instruction itself must not be changed as 
a consequence of instruction execution. 

There is a third type of operand, called memory operand , which 
will be detailed in section 6.1.1.3. 

In general, a two-operand instruction such as "CMP4" (compare) 
can have any combination of opercind types: 



CMP4 
CMP4 
CMP4 
CMP4 
CMP4 
CMP4 
CMP4 
CMP4 
CMP4 



literal, literal 
literal, register 
literal, memory 
register, literal 
register, register 
register, memory 
memory, literal 
memory, register 
memory, memory 



Each instruction, such as ADD4, determines what combinations 
of operand types is legal. This is done through attributes 
as described in section 6.1.5. Illegal combinations are only 
illegal because of the logic of the situation, such as the 
inadmissibility of storing into a literal. 

The encoding of instructions and their operands is orthogonal, 
as detailed in section 6.1.2. This means that the encoding 
places no restrictions on the selection of operand types. 
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6.1.1.1 Register Operands 



Registers X0..X15 are 32-bit entities each. They can be used 
singly, in pairs, or in quads. A pair of registers Cein be 
used as a single 64-bit operand, as follows: 



singly 12.. 



paired 12 
(X3|X4) 



.31 12 

+ + 



X3 



31 



X4 



— + + 

31 32 33 ., 



63 



Register pairs always involve consecutive registers Xi and 
Xi+1; register X15 can form a pair with XO. Register pairs are 
encoded in an instruction by encoding the first register in the 
pair. 

Register quads can be used to form a single 128-bit operand. 
Such a quad always involves consecutive registers Xi, Xi+1, Xi+2 
and Xi+3; again, register numbers wrap around, such that XO 
comes after X15. A register quad is encoded in an instruction 
by encoding its first register. 

A (single) register can also be used to hold operands smaller 
than 32 bits. Sections 6.1.6 and 6.1.7 go into more detail. 



6.1.1.2 Literal Operauids 



Literal Operands of up to 32 bits long can be encoded in an 
instruction. Uhen used in instructions that involve data types 
bigger than 32 bits, such a literal value will be extended to 
the right size by replicating the "left-most" (most-significant) 
bit. If the literal represents a two's complement integer this 
corresponds to sign extension . If the literal is anything else, 
this may not correspond to sign extension. Literal processing 
in the VISION architecture does not depend on the data type. 
Uhen used in instructions that involve data types smaller than 
32 bits, the literal value will be left- truncated to the desired 
number of bits without overflow indication. 
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6.1.1.3 Memory Operands 



Memory operands are operands that have a logical address. 
This logical address is found in one of the base registers 
B0..B7 (B6 is better known as Q; B7 as S) and modified through 
adding an index and/or a displacement. The rules for address 
arithmetic on memory operands are detailed below. In any case, 
the result will be a logical address, called the effective 
logical address. The use of this effective logical address is 
under control of the instruction. 

Typically, the effective logical address is used in a memory 
access. For enanple, 

ADD4 Q, 84 

will use the address in base register Q to read a 4-byte value 
from memory in order to add this to the 4-byte value read from 
memory at the logical address in B4. The result of the addition 
will be written back as a 4-byte value to memory at the logical 
address in B4. 

The effective logical address is occasionally needed for other 
purposes. During string moves, the logical addresses of source 
and target areas are incremented such as to sweep through the 
areas in memory. In the MOVEADR instruction, the effective 
logical address of the first operand is itself the value stored 
in the second operand; thus making the address arithmetic logic 
available to software, e.g. in building reference parameters. 
These other uses are the ones where register operands aire not 
suitable; registers cannot be addressed. The set of registers 
X0.,X15 exist outside logical address space. 

Base register operands night be regarded as a final way to 
use what looks like a memory operand. See section 6.1.1.3.2. 
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6.1.1.3.1 Computing the effective logical address 



A memory operand designates a base register, a displacement 
and an optional index register. The base register is one of 
B0..B5, Q, S; the index register is one of X0..X15 and the 
displacement is much like a literal in that it is contained 
in the instruction itself. The displacement is up to 32 bits 
in length. 

The designated base register contains a logical object id and 
a logical offset. The effective logical address will have the 
sane logical object id as the designated base register: the 
address computation does not carry into the object portion of 
the base register. Effective logical address computation 
consists of the two's complement addition of the 32-bit logical 
offset of the base register, the 32-bit displacement and the 
32-bit index (if present) and ignoring overflow and/or carry. 

Note that this allows implementations to perform the additions 
in any order. 



6.1.1.3.2 Base register operands 



Several instructions expect a base register as an operand. 
This is indicated through the "b" attribute as described in 
section 6.1.5. A base register operand is encoded like a 
memory operand; but no memory access is implied and the result 
of the effective address computation, if performed at all, is 
irrelevant. For a base register operand, the only relevant 
field is the base register field in the encoding for the memory 
operand . 
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6.1.2 Instruction Encoding 



Instructions consist of an opcode and a list of descriptors for 
each operand. 

The opcode identifies uniquely which operation to perform, the 
data type involved and the number of operands. 

The Vision instruction set is "operand-modular": that is, each 
operand individually and independently can be chosen to be a 
register, a literal or a memory operand. 
The encoding scheme presented here is such that hardweire can 
efficiently decode and execute instructions, code generators 
can conveniently emit Vision object code in this format, and 
the scheme is reasonably space efficient. 

In the basic scheme instructions are multiples of 4 bytes in 
length and word-aligned in logical address space (also in 
virtual address space) . This scheme is described in section 
6.1.2.1. A variant of this scheme allows denser packing of 
instructions; it is described in section 6.1.2.2. 



6.1.2.1 Basic instruction encoding scheme 



Opcodes are encoded in 8 bits. An operand descriptor consists 
of an 11-bit operand specifier OPSPEC optionally accompanied 
by a 32-bit operand completion COMPL. The completion is used 
when the 11 bits of the operand specifier do not suffice to 
uniquely determine the operand; these cases correspond to the 
first 3 bits of the operand specifier OPSPEC[0..2] being zero. 
Operands are encoded in pairs; if the instruction has an odd 
number of operands, an additional dummy operand (e.g. literal 
zero) is specified. 

The sketch below shows an instruction with 4 operands. Note 
that the first two bits of the instruction words are both one 
in order to identify that the basic format is used. Note also 
that the 8-bit OPCODE is found by concatenating bits 2.. 4 and 
bits 16.. 20 of the first instruction word. The address of 
the instruction (e.g. when used as a branch target) is the 
address of the first byte of the first word of the instruction. 
Note that, in this format, the instruction address is a multiple 
of four. 
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1 2 3 
01 234 56789012345 67890 12345678901 

P = = > miOPC I OPSPECl rODE I 0PSPEC2 | 

(2) (3) (11) (5) (11) 

+ + + + _+ 

P+4==> I COMPLl (only if OPSPECl [0 .. 2] =0 ) I 

+ . — + .' -+ + + 

+ + + + + 

P+8==> I C0MPL2 (only if 0PSPEC2[0. .2]=0) | (at P+4 if 

+ + + + + COMPLl absent) 

+__+ + + + + (at p+8 if 

P+12=> I mbl I 0PSPEC3 I mbl I 0PSPEC4 | COMPLl or C0MPL2 
+ — + + _ — + + + absent; at P+4 

if both absent) 

+ _ + 

P+16=> I C0MPL3 (only if OPSPEC3[0..2]=0) | (etc.) 

+ + 

+ + 

P+20=> I C0MPL4 (only if OPSPEC4[0. .2]=0) I 



Note: mbl (must be ones) denotes a field that should consist 
of all ones. It is the resfponsibility of software to 
ensure this; hardware implementations nay assume ones 
in these fields without having to check this. 
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6.1.2.2 Dense Instruction Encoding Scheme 



This is a variant of the basic encoding scheme that allows some 

instructions to be packed two per word. 

A subset of 24 instructions are candidates for this more densely 

packed scheme. These instructions are such that OPCODE[0] and 

0PC0DE[1] are not both one. Instructions in this subset are all 

single operand instructions. 

If two consecutive instructions are both in this subset, the 

pair qualifies. For such a pair, the sequence 

OPCODEa OPERANDa ; OPCODEb OPERANDb; 

can be encoded as: 



12 3 
01234 56789012345 67890 12345678901 



words of 
increasing 
address in the 
code stream 
\/ 



1 opa 1 OPSPECa 1 opb | 


OPSPECb 1 


(5) (11) (5) 


(11) 


1 COMPLa (if OPSPECa[0. 


.2]=0) 1 




1 COMPLb (if OPSPECb[0. 


.2]=0) 1 



Note 1: 0pa=0PC0DEa[3..7] and opb=0PC0DEb[3. .7] . 

(i.e. OPCODEa = lEO + opa; OPCODEb = !E0 + opb) 

Note 2: Bits and 1 of the first instruction word in this 
packed format are never both one, so the two formats 
can be distinguished. 

Note 3: The second instruction in such a pair can be a branch 
target. The P-value corresponding to the second 
instruction in such a pair is taken to be the address 
of the byte containing "opb"; this is on an even byte 
this is on an even byte boundary. All branch targets 
will be even byte addresses. 
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6.1.2.3 Secondairy Instruction Set Encoding 



A few of the 8-bit opcodes act as an escape to a secondary 

instruction set. The opcode "SYS" is one of these. 

Most operating system support instructions, including the I/O 

instruction sets, are in this secondary instruction set. 

This section describes their encoding. The instruction "PDDEL" 

(delete from page directory) will serve as an example. 

PDDEL is in the secondary instruction set for "SYS". It has a 

single operand "ppn". In the opcode assignment chart PDDEL is 

listed as having a secondary opcode of 109 (hexadecimal) or 9. 

The instruction: 

PDDEL ppn 
is encoded as if it were: 

SYS 9, ppn 

with the "9" encoded as a short literal (see section 6.1.3.1). 
In other words, the secondary opcode is treated as an additional 
literal operand of the primary escape opcode. Implementations 
may differ in their results if the secondary opcode is encoded 
as an operand other than a short literal. 



6.1.2.4 Code Bounds Violations 



The object identified by P is called the current code object. 
PB denotes the first byte of the current code object; PL 
denotes the first byte beyond the current code object; both are 
multiples of four. Hardware checks P against PB and PL on all 
transfers of control. Hardware may also check P against PL 
when executing instructions not involving tramsfer of control. 
The effect of executing an instruction that starts within the 
current code object but has completion words that fall outside 
of it may differ across implementations. 
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6.1.3 Operand descriptors 



An operand descriptor consists of an ll-bit operand specifier 
OPSPEC accompanied by a 32-bit operand completion COMPL when 
OPSPEC[0..2]=000. The formats of the operand specifiers are 
detailed in the sections below, ("mbz" means "must be zero"; 
hardware may assume an mbz field to be zero without having to 
check this. ) 



6.1.3.1 Short literal 



The value of the operand is obtained 
from the OPSPEC itself, through sign- 
extension of the 8-bit literal field. 



01234567890 



|0 1 01 



literal 



6.1.3.2 Long literal 



The value of the operand is obtained 
from the 32-bit COMPL. lor data 
types > 4 bytes this value is then 
sign- ex tended. 



6.1.3.3 Register operand 



The operand is the designated index 
register. For data types > 4 bytes, 
a pair or quadruple of consecutive 
registers is designated. 



-+-+-+-+-+-+-+-+-+ 



01234567890 
10 1 II mbz I 



01234567890 
10 1 1| Xj I mbz I 



6.1.3.4 Memory operand (base+short word displacement) 



The operand is in memory. The logical 
address is given by a base register 
to which is added U0RDDISPL*4. 
Note that UORDDISPL is zero- ex tended. 
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6.1.3.5 Memory operemd (base-short word displacement) 



The operand is in memory. Its logical 
address is given by a base register 
to which is added the one-extended 
U0RDDISPL*4. 



01234567890 
|0 1 lIUORDDISPLlBASEil 



6.1.3.6 Memory operand (base+long displacement) 



The operand is in memory. Its logical 
address is given by a base register 
to which is added the two's complement 
byte displacement found in the 32-bit 
COMPL. 



01234567890 
|0 1 01 mbz IBASEij 



6.1.3.7 Memory operand (base+ index) 



The operand is in memory. Its logical 
address is given by a base register 
to which is added the two's complement 
32-bit value found in the designated 
index register. 



01234567890 
10 1 01 xj IBASEij 



6.1.3.8 Memory operand (base+index+ displacement) 



The operand is in memory. Its logical 
address is given by a base register 
to which is cidded the two's complement 
32-bit value found in the designated 
index register and also the two's 
complement 32-bit displacement value 
found in the 32-bit COMPL in the 
instruction itself. 



01234567890 
|0 01 Xj iBASEil 
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6.1 


4 Opcode Assignments 










The following chart shows opcode assignments for instructions in 


















the secondary instruction set in the escape group for "SYS", 


The 


following chart 


shows the 


association of opcodes with the 








instruction 


name (mnemonic) . 


The 8-bit encoding of the opcode 




SYS 




is i 


found by adding the hexadecimal number in the row of the 




OPCODE 




instjruction 


to the hexadecimal number 


in its column. 






+100 +101 +102 +103 +104 +105 +106 


+ 107 


















100 lEXIT SWITCH * RSUITCH IDLE STOP * 


* 


















108 PDINS PDDEL SYNCOD GROUGDO * * * 


* 


OPCODE 














110 SYNCTCB SYNCIB CVLAtVA HASH CWAtPP LAUNCH * 


* 




+ 100 


+ 101 


+ 102 


+ 103 


+104 +105 


+ 106 


+ 107 


118* * * * * * * 


* 


100 


ERROR 


NOP 


EXIT 


SEXIT 


TESTA TESTE 


TESTOV 


BREAK 


#120 lOU lOB IOC * * * * 


# 


!08 


* 


* 


* 


* 


PSEB PSDB 


DISP 


TRY 


128* * * * * * * 


# 


ilO 


DISABLE 


ENABLE 


INTERRUPT UNTRY 


EXTEND DELETE 


CHECKA 


CHECKB 


1 30* * * * * « * 


* 


!18 TESISTRIP* 


* 


* 


* BRX 


* 


* 


$138 IFC UCMD UBYTE RBYTE * * * 


* 


!20 


* 


* 


QUAD4 


* 


POPS * 


* 


P0P16 


$140 CHNOP RCL PRD PDA PAR RDP UDP 


RIS 


!28 


PUSHl 


PUSH2 


PUSH8 


# 


TESTDOUN UP 


DOUN 


PUSH16 


$148 CIS SIS * * * * * 


* 


130 


POPl 


P0P2 


* 


* 


* TESTREF 


* 


TEST16D 


150* * * * * * * 


* 


!38 


* 


TEST2 


TEST8 


TEST4F 


TEST4D TEST8D 


TEST8F 


TEST16F 


1 58 MOVEtCSP* ***** 


* 


!40 


AND4 


* 


* 


MPY4F 


MPY8 * 


MPY8F 


MPY16F 


* * * * # # * 


* 


148 N0T4 


* 


DIV4 


DIV4F 


DIV8 * 


DIV8F 


DIV16F 


IPS* * * * * ** 


* 


!50 


0R4 


REM4 


NEG4 


NEG4F 


NEG8 REM8 


NEG8F 


NEG16F 






!58 


X0R4 


M0D4 


ABS4 


ABS4F 


ABS8 MODS 


ABS8F 


ABS16F 






160 


CMPl 


CMP2 


CMP4 


CMP4r 


CMP8 BCMP8 


CMP8F 


CMP16F 


Note 1: the I/O instructions in the rows marked "#" are 


defined 


168 


MOVEl 


M0VE2 


M0VE4 


* 


MOVES BSET8 


* 


M0VE16 


for MPB-based implementations. On any other 




170 


TESTBIT 


ISC42 


ADD4 


ADD4F 


ADDS BGET4 


ADD8F 


ADD16F 


implementation these instructions will cause a 


trap. 


178 


* 


MPY4 


SUB4 


SUB4F 


SUBS BSET4 


SUB8F 


SUB16F 






180 


MOVEADR 


BMOVEADR* 


* 


* * 


* 


* 


Note 2: the I/O instructions in the rows marked "$" are 


defined 


188 


* 


* 


M0VEfSP4 M0VEfSP8 TESTSEMA* 


* 


* 


for PICMB-based implementations. On any other 




190 


* 


* 


M0VEtSP4 MOVEtSPS MOVESEMA* 


# 


# 


implementation these instructions will cause a 


trap. 


198 


CHECKLO 


CHECKHI 


DUP 


OVPUNCH 


CVID CMP4D 


CMP8D 


CMP16D 






lAO 


LSL4 


ASL4 


BCMP4 


GETSIC31 


CVDI ADD4D 


ADDSD 


ADD16D 






1A8 


LSR4 


ASR4 


BADD4 


VALN 


CVAD SUB4D 


SUB8D 


SUB16D 






IBO 


LSL8 


ASL8 


BSUB4 


VALD 


CVDA MPY4D 


MPY8D 


MPY16D 






188 


LSR8 


ASR8 


* 


* 


* DIV4D 


DIVSD 


DIV16D 






ICO 


PROBE 


* 


MOVEBIT 


MOVEC 


SRD MOVED 


MOVEBLR 


CMPB 






!C8 


DPF 


* 


REP 


CMPC 


SLD TRANSL 


MOVEBRL 


CMPT 






IDO 


P0LY4F 


P0LY8F 


P0LY16F 


SCANUNTIL* * 


* 


* 






1D8 


# 


* 


* 


* 


* VECTOR 


SYS 


CONVERT 






@1E0 


BRG 


BRGE 


BRGL 


BRNU 


PUSH4 PUSHADR 


P0P4 


BP0P8 






(3)1 E8 


BRGU 


BRNL 


BRNE 


BR 


TESTLSB TESTl 


TEST4 


BTESTS 






@1F0 


BRN 


BRE 


BRL 


BRLE 


CALL CALLX 


* 


BREAK 






!F8 


BRU 


BREU 


BRLU 


BRNG 


# * 


* 


ERROR 






Note 1: the 


rows marked with 


"ffl" contain the instructions that 








can 


be packed two per word. 












Note 2: the 


instructions VECTOR and SYS are escapes to a 










secondary set of opcodes. 
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The 


chart 


given 


below shows the 


association between vector 


6.1.5 Attributes 


instructions and their 


opcodes. 


All these are 


secondary 




opcodes in the 


"VECTOR' 


escape 


group. 
























Attributes can be associated with operands or with instructions. 


VECTOR 
















OPCODE 














6.1.5.1 Operand Attributes 




+ !00 


+ !01 


+ !02 


+ !03 


+ !04 


+ !05 


+!06 +!07 




!00 


VMQVE2* 


VM0VE4 


* 


VM0VE8 


* 


VM0VE16 * 




!08 


VABS 


* 


VABS4 


VABS4F 


VABS8 


VABS8F 


* VABS16F 


Each instruction has an implied number of operemds and for each 


!10 


* 


* 


VNEG4 


VNEG4F 


VNEG8 


VNEG8F 


* VNEG16F 


operand of the instruction there is an implied attribute. 


!18 


* 


* 


VLSL4 


* 


VLSL8 


# 


* * 


For eKample, section 6.2.2 shows the ADD4 instruction in the 


!20 


* 


* 


VLSR4 


* 


VLSR8 


* 


* * 


following way: 


128 


* 


* 


VASL4 


* 


VASL8 


* 


* * 




!30 


* 


* 


VASR4 


* 


VASR8 


* 


* * 


ADD4 terra. r4, sum.rw4 


!38 


* 


* 


* 


* 


* 


* 


* * 




!40 


* 


* 


* 


* 


* 


* 


* * 


Here "term" and "sum" are merely symbolic names for the two 


!48 


* 


* 


* 


* 


* 


* 


* * 


operands; ".r4" and ".rw4" are the operand attributes. 


!50 


* 


* 


VCMPRS4 


* 


VCMPRS8 


* 


VCMPRS16* 


These attributes are ccmposed of individual elements like "r", 


!58 


* 


* 


VEXPND4 


* 


VEXPND8 


* 


VEXPND16* 


"w", and "4". 


!60 


* 


* 


VACC4 


VACC4F 


VACC8 


VACC8F 


* VACC16F 




!68 


* 


* 


* 


VACCD4F 


* 


VACCD8F 


* * 


The "r" attribute indicates that the operand must allow reading 


!70 


* 


* 


VMAXL4 


VMAXL4F 


VMAXL8 


VMAXL8F 


* VMAXH6F 


from; hence it can be a literal, a register or a memory opersind 


!78 


* 


* 


VMINL4 


VMINL4F 


VMINL8 


VMINL8F 


* VMINL16F 


with appropriate read access rights. 


!80 


* 


# 


VADD4 


VADD4F 


VADD8 


VADD8F 


* VADD16F 




!88 


* 


* 


VSUB4 


VSUB4F 


VSUB8 


VSUB8F 


* VSUB16F 


The "w" attribute indicates that the operand must allow writing 


i90 


* 


* 


VMPY4 


VMPY4F 


VMPY8 


VMPY8F 


* VMPY16F 


to; hence it must not be a literal, but must be a register or a 


!98 


* 


* 


VDIV4 


VDIV4F 


VDIV4F 


VDIV8F 


* VDIV16F 


memory operand with appropriate write access rights. 


lAO 


* 


* 


VAND4 


V0R4 


VAND8 


V0R8 


* * 




!A8 


* 


* 


VX0R4 


* 


VX0R8 


* 


* * 


The "4" attribute indicates that the operand is a 4-byte entity; 


!B0 


* 


* 


VGATH4 


VSCAT4 


VGATH8 


VSCAT8 


VGATH16 VSCAT16 


this has obvious implications for memory operands with respect 


!B8 


* 


* 


VEXT4 


VINS4 


VEXT8 


VINS8 


VEXT16 VINS16 


to memory access and bounds checking. 


!C0 


* 


* 


VREM4 


* 


VREM8 


* 


* * 




!C8 


* 


* 


VM0D4 


* 


VM0D8 


* 


* * 


operand | stands 1 1 1 


!D0 


* 


* 


VCMP4 


VCMP4F 


VCMP8 


VCMP8F 


* VCMP16F 


attribute I for: | LITERAL | REGISTER 1 MEMORY 


!D8 


* 


* 


* 


* 


* 


* 


* * 


+ + + + 


!E0 


CLRMR 


STMR 


LDMR 


MRNOT 


MRAND 


MROR 


MRXOR * 


r 1 read I ok 1 ok 1 check OD.TYP&AR 


1E8 


LDVLR 


STVLR 


RVLRT 


* 


* 


* 


* # 


w 1 write I illegal j ok I check OD.TYP&AR 


•FO 


UVCSA 


PUVCSAIVB 


LVB 


VINVAL 


# 


* * 


m 1 memory I illegal I illegal I ok 


!F8 


# 


* 


* 


* 


* 


* 


VCONVERT* 


b 1 base I illegal 1 illegal I ok 

c 1 code 1 illegal I illegal I if OD.TYP=code 

V 1 vector I (1) | (1) I (1) 

1 1 1-byte 1 (2) I (2) I check w/ OD.UB 

2 1 2-byte I (2) I (2) 1 check w/ OD.UB-1 
4 1 4-byte 1 (2) 1 (2) I check w/ OD.UB-3 
8 1 8-byte I (2) | (2) 1 check w/ OD.UB-7 

16 1 16-byte I (2) I (2) I check u/ OD.UB- 15 

Notes: (1): see section 6.4. 

(2): see sections 6.1.6 and 6.1.7. 










6-15 






6-16 



VISION ARCHITECTURE CONTROL DOCUMENT 07/31 


VISION ARCHITECTURE CONTROL DOCUMENT 07/31 


DO NOT COPY — HP PRIVATE INFORMATION 


DO NOT COPY — HP PRIVATE INFORMATION 


6.1.5.2 Instruction Attributes 


6.1.6 Sources 


Instruction attributes include the data type of the operation 


A source is a value derived from an operand that is of the right 


to be performed. For example, in: 


size to be used in the instruction. This section makes explicit 




the actions to be performed on read operands to turn them into 


ADD4F X3, X5 


a source. For example, in the instruction: 


the suffiK "4F" indicates that addition is to be performed on a 


ADDS 1, X3 


4-byte Floating point number according to the rules of floating 




point arithmetic on 32-bit numbers. 


the literal "1" is sign-extended to form a 64-bit source; the 




register X3 is paired with the register X4 to form a 64-bit 


A list of data types follows: 


register pair acting as a 64-bit source; both 64-bit numbers 




are then added together in two's complement arithmetic. (The 




result is then stored according to the rules in section 6.1.7.) 


instruction! interpretation 


The following chart makes this all explicit. 


attribute j 




— — — 1 — 

1 1 8-bit unsigned integer, or any 1-byte entity 


1 source (in bytes) 


2 1 16-bit two's complement integer/any 2-byte entity 


operand descr. I 1 2 4 8 16 


1 
4 1 32-bit two's complement integer /any 4-byte entity 


1 


8 1 64-bit two's complement integer /any 8-byte entity 


short literal I as is SE16 SE32 SE64 SE128 


16 1 128-bit entity of any type 


1 


1 


long literal I TR8 TR16 as is SE64 SE128 


4F 1 32-bit IEEE floating point 


1 


8F 1 64-bit IEEE floating point 


register opnd I TR8 TR16 as is pair quad 


16F 1 128-bit IEEE floating point 


1 


1 


memory operand I Rl R2 R4 R8 R16 


40 1 32-bit packed decimal 


1 


80 1 64-bit packed decimal 




160 1 128-bit packed decimal 


where: 




SEn = sign-extend to n bits. This always means replicating the 




lowest numbered bit regardless of data type. 




TRn = truncate. This always means discarding all but the n 




rightmost bits. 




pair = pair with following register. XO follows X15. 




quad = pair with following 3 registers. 




Rn = Read n consecutive bytes from memory starting at the 




effective logical address. Check the object type in the 




00 for the logical object; check the read access rights 




at the current privilege level; check bound LB and UB-n+1 




(both inclusive) . 
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6.1.7 Destinations 

The result of an operation may have to be massaged before it 
can be stored away. This section makes these operations 
explicit. 
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operand descr. I 1 



destination (in bytes) 
2 4 8 



16 



short literal i illegal illegal illegal illegal illegal 

I 
long literal I illegal illegal illegal illegal illegal 

I 
register opnd I ZE32 SE32 as is pair quad 

I 
memory operand I Ul U2 U4 118 U16 

I 

where: 

illegal = a literal operand must not occur in this context. 

ZE32 = right- justify and zero-extend to 32 bits 

SE32 = sign-extend, i.e. replicating the lowest numbered 
bit, to 32 bits. 

pair = pair with following register. XO follows X15. 

quad = pair with following 3 registers. 

Un = write n consecutive bytes to memory starting at the 
effective logical address. Use the OD of the object 
to check type and write access rights. Use the bounds 
in the OD for bounds checking: LB and UB-n+1. (both 
inclusive) 
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6.1.8 Traps 



Traps are described in detail in chapter 7. Chapter 6 shows 
the conditions under which traps occur as the necessary result 
of instruction execution, but it does not show the parameters 
passed to the trap handler, nor does it show the pervasive 
traps and conditions such as power-fail, page fault, etc. 
In particular, it does not show any of the traps in the list 
below under the heading of "Opnd" that can occur on operand 
accessing. 



Opnd ; can be any of 



OPSPECV 

DATATYPV 

DATAODTV 

DATAARV 

DATABNDSV 



AddressingV : can be any of the above, but in accesses other 
than those involving explicit operands 



Arith: can be any of 



INTOVF 
INTDVDZ 



FlArith: can be any of FLINV 
FLDVDZ 
FLOVF 
FLUNF 
FLINX 



DecArith : can be any of DECINVL 
DECOVF 
DECDVDZ 
DECINVDG 
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6.2 Base Instruction Set 



6.2.1 Data Movement Instructions 



6.2.1.1 MOVEt source. r, destination. ¥ 

Move data element. The value of "source" is copied to 

"destination". The number of bytes moved is implied 
by the type "t". Partial overlap of the areas 
containing source and destination may give results that 
differ across implementations. 



destination 



includes: MOVEl M0VE2 M0VE4 M0VE8 M0VE16 



6.2.1.2 MOVEADR operand. m, destination. tii8 

Move logical address. The 64-bit logical address of "operand" 
is computed and the result stored in "destination". 
"Operand" must be a memory operand. The byte that is 
addressed by "operand" requires neither legal read nor 
Mrite access, nor need it be within the logical object 
bounds. This instruction makes the operand-addressing 
hardware available to software, e.g. for building 
reference arguments. This instruction also doubles 
as a way to obtain the value in a given base register; 
for this usage the assembly language alias "BGET8" is 
provided. 



destination := log ical_address_of (operand); 
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6.2.1.3 PUSHt source. r 

Push data element. The value of "source" is copied into a 

temporary register of length 4 bytes (for PUSHl, PUSH2, 
PUSH4): of length 8 bytes (for PUSH8) or 16 bytes (for 
PUSH16). For PUSHl, "source" is zero-extended to 32 
bits; for PUSH2, "source" is sign-extended to 32 bits. 
The temporary is then pushed onto the stack. After 
PUSHt, the top-of-stack register S will point to the 
first byte beyond the data that was moved. On stack 
overflow, S will be restored to the value it had before 
the instruction. 

Temp[0..k] := source; 

{zero- ex tend for t=l. 
sign-extend for t=2) 
S := S + m; 
(S-m)[0..k] := Temp[0..k]; 

{Here for t = 1, 2, 4, 8, 16 
use k =31,31,31,63,127 
and m = 4, 4, 4, 8, 16} 



Traps: 



PUSHl PUSH2 PUSH4 PUSH8 PUSH16 
STKOVF STKOVF STKOVF STKOVF STKOVF 



6.2.1.4 PUSHADR operand. m 

Push logical address. The 64-bit logical address of "operand" 
is computed and pushed onto the stack. "Operand" must 
be a memory operand. 

PUSHADR also doubles as a way to push the value of a 
base register onto the stack; for this usage the 
assembly language alias "BPUSH8" is provided. 



MOVEADR operand, Temp; 
PUSH8 Temp; 



Traps: STKOVF 
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6,2,1.5 POPt destination.u 

Pop data element. A number of bytes given by "t" are popped 
off the stack and stored in "destination". In case 
less than 4 bytes are popped, the top-of-stack register 
S is further decremented so as to remain word-aligned. 
On stack underflow, S is restored to the value it had 
before the instruction. 



destination 
S := S - m; 



(S-t)[0..p]; 



Traps: 



{Here for t = 1, 2, 4, 8, 16 
use p = 7,15,31,63,127 
and m = 4, 4, 4, 8, 16} 



POPl P0P2 P0P4 P0P8 P0P16 
STKUNF STKUNF STKUNF STKUNF STKUNF 



6.2.1.6 DPF value. r4, shiftcount.rl, mask.r4, target. rw4 

Deposit Field. "Value" is deposited in a field of "target" 
identified by "shiftcount" and "mask". "Mask" is 
assumed to be of the form 

2^31 - ( 2'"fieldsize - 1 ) * 2^shiftcount 
but if it is not, the following definition still 
applies. However, implementations may substitute 
a circular shift for the logical shift indicated. 



M0VE4 


value, Val; 






LSL4 


shiftcount, Val; 


{see 


6.2.3) 


M0VE4 


target, Tgt; 






AND4 


mask, Tgt; 


{see 


6.2.3) 


0R4 


Val, Tgt; 


{see 


6.2.3) 


M0VE4 


Tgt, target ; 
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6.2.1.7 MOVEC length.r4, source. mr, destination. mw 

Counted move of bytes. This instruction moves a string of 
contiguous bytes starting at the logical address 
given by the specifier for "source" and of length 
"length" to the area of equal length starting at 
the logical address given by the specifier for 
"destination". If "length" is negative or zero, 
no bytes are moved. If conditions (a) or (b) are 
violated, implementations may yield different 
results; however, in no case should reads or writes 
to memory be performed in violation of access rights. 

a) the source and destination area must not overlap 

b) "length" must not be in the destination area 

The MOVEC instruction is interruptible, at intervals 
determined by each implementation. 



if IIP = then C := 
else P0P4 C; 
IIP := 0; 

MOVEADR source, Fromla; 
MOVEADR destination. Tola; 
Lgth := length [0.. 31 J - 1; 
while C < Lgth do 
begin 

Byte := (Fromla + C)[0..7]; 

(Tola + C)[0..7] := Byte; 

C := C + 1; 

{if implementation chooses to acknowledge 
external interrupts here, then 
PUSH4 C and set IIP := 1} 
end; 



Traps: AddressingV 
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6.2.1.8 MOVEBIT bitindex.r4, source. rl, bitarray.mrw 

Move a bit. The least significant bit of "source" is stored 
in the array of bits (t0hose first byte is addressed 
by "bitarray") at the index "bitindex". All other 
bits of "source" are ignored. "Bitindex" is an 
arbitrary two's complement integer. Only the address 
of the byte in which the bit is actually stored need 
be within the bounds of the logical object. No other 
bits in the byte are disturbed. Memory interlock is 
not guaranteed (see lESTSEMA). 



MOVEADR bitarray, Addr; 

Source_byte[0. .7] := source; 

Bit := Source_byte[7]; 

Byte offset := bitindex [0. .28] {sign-extended}; 

AddrT32..63] := Addr[32.,63] + Byte_Gffset; 

Bit_number := bitindex[29. .31] ; 

Byte[0..7] := (Addr) [0. .7] ; 

Byte[Bit_number] := Bit; 

(Addr) [0,. 7] := Byte; 
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Traps: AddressingV 
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6.2.1.9 MOVEBLR fillchar, srcl, src, destl, dest 

MOVEBLR fillchar. rl, srcl.r4, src.mr, destl. r4, dest. raw 

Move bytes left- to-right. This instruction moves a string of 

contiguous bytes starting at the logical address given 
by "src" and of length "srcl" to the logical address 
given by "dest" and of length "destl". If "destl" is 
<=0, nothing is moved. If "srcl" > "destl", the string 
is truncated on the right. If "srcl" < "destl", the 
string is padded on the right with "fillchar". Overlap 
between "src" and "dest" areas is explicitly allowed; 
the algorithm below defines the intended effect. 



if IIP = then C := 

else P0P4 C; 

IIP := 0; 

MOVEADR src, Lfrom; 

MOVEADR dest, Lto; 

SI := srcl; Dl := destl; F := fillchar; 

while C < Dl do begin 

if C < SI 

then (Lto+C)[0..7] := (Lfrom+C) [. .7] 

else (Lto+C)[0..7] ;= F; 

C := C + 1; 

{ if implementation chooses to acknowledge 
an external interrupt here, 
then PUSH4 C and set IIP := 1 } 

end: 



Traps: AddressingV 
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6.2.1.10 MOVEBRL fillchar, srcl, src, destl, dest 

MOVEBRL fillchar. rl, srcl.r4, src.mr, destl, r4, dest.mw 

Move bytes right- to- left. This instruction moves a string of 

contiguous bytes starting at the logical address given 
by "src" and of length "srcl" to the logical address 
given by "dest" and of length "destl". If "destl" 
<=0, nothing is moved. If "srcl" < "destl", the string 
is padded on the left with "fillchar". If "srcl" > 
"dstl", the string is truncated on the left. Overlap 
between "src" and "dest" areas is explicitly allowed: 
the algorithm below defines the intended effect. 



if IIP = then C := 

else P0P4 C; 

IIP := 0; 

MOVEADR src, Lfrom; 

MOVEADR dest, Lto; 

SI := srcl; Dl := destl; F := fillchar; 

while C < Dl do begin 

if C < SI 

then (Lto+C)[0..7] := (Lfrom+C) [0. .7] 

else (Lfrom+C) [0.. 7] := F; 

C := C + 1; 

{ if implementation chooses to acknowledge 
an external interrupt here, 
then PUSH4 C, and set IIP := 1 } 

end; 



Traps: AddressingV 
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6.2.1.11 TRANSL table. mr, length.r4, source. mr, dest.mw 

Translate. Contiguous bytes from "source" are moved to "dest" 
one at a time by using the byte from "source" to 
index into "table" and the byte found in "table" is 
stored at "dest". 

A count of "length" bytes is moved; if "length" is 
not positive, no bytes are moved. 



then 
C: 



if IIP = 
else P0P4 
IIP := 0; 
MOVEADR source 
MOVEADR 
MOVEADR 
while C 

Byte := 

Byte := 

(Lto+C) 

C := C 



C := 



dest, 

table, 

< 



Lfrom; 

Lto; 

L table; 
length do begin 
(Lfrom+C) [0., 7]; 
(Ltable+Byte)[0..7]; 
:= Byte; 

1; 

{if implementation chooses to acknowledge an 
external interrupt here, 
then PUSH4 C, and set IIP := 1 } 

end; 



Traps: AddressingV 
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6.2.1.12 DUP wordcount.r4, value. r4 


6 . 2 . 1 . 14 EXTEND wordcount . r4 


Duplicate. The 32-1)11 value "value" is pushed onto the stack 


EKtend top-of-stack. Base register "S" is incremented by four 


a "wordcount" nuntier of times. This instruction must 


times the value of "wordcount", which must be positive. 


be interruptible. 


On stack overflow S will be restored to its original 




value and a trap taken. Ring level 1 is required. 


if IIP = then C := 1 




else P0P4 C; 


if XL>1 then Trap"INSPRIV"; 


IIP := 0; 


if wordcount < then Trap"SIKDEXTV"; 


while C <= wordcount [0. .31] do begin 


if S + 4 * wordcount <= SL then Trap"STKOVF"; 


PUSH4 value; 


S : = S + 4 * wordcount; 


C := C + 1; 




{if implementation chooses to acknowledge 




interrupts here, 


Traps: INSPRIV 


then PUSH4 C and set IIP := 1} 


STKDEXTV 


end; 


STKOVF 


Traps: STKOVF 






6.2.1.15 DELETE wordcount. r4 




Delete from top-of-stack. Base register "S" is decremented by 


6.2.1.13 REP wordcount. r4, value. r4, operand. raw 


four times the value of "wordcount", which must be 




positive. If the new S would end up below Q, the 


Replicate. The 32-bit value "value" is stored in "wordcount" 


original S will be restored and a trap taken. 


consecutive words of memory starting at the address 




of "operand". If the buffer to be initialized with 




"value" overlaps with either "wordcount" or "value", 


if wordcount < then Trap "STKDEXTV; 


implementations may produce different results. 


if S - 4 * wordcount < Q then Trap"STKUNF"; 


This instruction must be interruptible. 


S := S - 4 * wordcount; 


if IIP = then C := 1 


Traps: STKDEXTV 


else P0P4 C; 


STKUNF 


IIP := 0; 




MOVEADR operand, Toaddr; 




while C <= wordcount [0. .31] do begin 




(Toaddr + 4*C )[0..31] := value; 




C := C + 1; 




{if implementation chooses to acknowledge 




interrupts here, 




then PUSH4 C and set IIP := 1} 




end; 




Traps: AddressingV 
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6,2.2 Arithmetic Instructions 


6.2.2.4 DIVt divisor. r, dividend, rw 




Divide. "Dividend" is divided by "divisor" and the result 


This section includes instructions for arithmetic operations on 


stored in "dividend". On integer divide with "divisor" 


the integer and floating point scalar data types. Decimal 


zero, the new value of "dividend" is indeterminate; 


arithmetic is covered in section 6,3, vector arithmetic is 


however, the sign of "dividend" should not be changed. 


covered in section 6.4, 


For integer divide, the algebraic result is truncated 




towards zero. On integer overflow, "dividend" is left 




as zero. 


6.2,2.1 ADDt term.r, sum,nii 






DIV4 DIV8 DIV4F DIV8F DIV16F 


Add. "Term" is added to "sum" and the result is stored in 


Status: Ovflow Ovflow FlFlags FlFlags FlFlags 


"svuu". In case of integer overflow, "sum" is set to 


Traps: Arith Arith FlArith FlArith FlArith 


the least significant bits of the correct mathematical 


INTDVDZ INTDVDZ 


result. 




ADD4 ADDS ADD4F ADD8F ADD16F 




Status: Ovfl Ovfl Flflags Flflags Flflags 


6.2.2.5 NEGt source. r, destination. w 


Traps: Arith Arith FlArith FlArith FlArith 






Negate, "source" is negated (subtracted from zero) and the 




result is stored in "destination". On integer 




overflow, "destination" is left as the leirgest 


6.2.2.2 SUBt term.r, difference. rui 


negative value. 


Subtract. "Term" is subtracted from "difference" and the result 




is stored in "difference". In case of integer overflow 


NEG4 NEG8 NEG4F NEG8F NEG16F 


"difference" is set to the least significant bits of 


Status: Ovflow Ovflow FlFlags FlFlags FlFlags 


the correct mathematical result. 


Traps: Arith Arith FlArith FlArith FlArith 


SUB4 SUBS SUB4F SUBSF SUB16F 




Status: Ovfl Ovfl Flflags Flflags Flflags 




Traps: Arith Arith FlArith FlArith FlArith 


6.2.2.6 ABSt source. r, destination. w 




Absolute value. The absolute value of "source" is computed 




and the result is stored in "destination". On 


6.2.2.3 MPYt factor. r, product. rw 


integer overflow, "destination" is left as the 




largest negative value. 


Multiply. "Factor" is multiplied by "product" and the result 




is stored in "product". In case of integer overflow, 


if source < then destination := - source 


"product" is set to the least significant bits of the 


else destination := source; 


correct mathematical result. 






ABS4 ABS8 ABS4F ABS8F ABS16F 


MPY4 MPY8 MPY4F MPY8F MPY16F 


Status: Ovflow Ovflow FlFlags FlFlags FlFlags 


Status: Ovfl Ovfl Flflags Flflags Flflags 


Traps: Arith Arith FlArith FlArith FlArith 


Traps: Arith Arith FlArith FlArith FlArith 
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6.2.2.7 REMt divisor. r, dividend. rw 

Remainder. The algebraic remainder of the division of "dividend" 
by "divisor" is computed and the result stored in 
"dividend". The remainder has the same sign as the 
old value of "dividend", and is less in absolute value 
than "divisor". The equation 

divisor * quotient + remainder = dividend 
always holds. If "divisor" is zero, the magnitude of 
"dividend" will be indeterminate. 



REM4 REM8 

Status: Ovflow Ovflow 

Traps: Arith Arith 

INTDVDZ INTDVDZ 



6.2.2.8 MODt divisor. r, dividend. rw 

Modulus. The modulus of "dividend" and "divisor" is computed 
and the result is stored back into "dividend". 
The modulus is defined to be the quantity that is 
positive (or zero) and less than the absolute value 
of "divisor", and such that the difference of modulus 
and "dividend" is a whole multiple of "divisor". 
This definition determines the modulus uniquely, except 
when "divisor" has the value zero, in which case the 
magnitude of "dividend" will be indeterminate. 
Note that the equation 

divisor * quotient + modulus = dividend 
will not always hold. 



M0D4 MODS 

Status: Ovflow Ovflow 

Traps: Arith Arith 

INTDVDZ INTDVDZ 
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6.2.2.9 POLYt degree. rl, polyn.mr, operand.™ 

Polynomial evaluation. This instruction computes the value of 
a polynomial evaluated for the value of "operand", 
storing the result back into "operand". The polynomial 
is defined by degree "degree" (interpreted as an 
unsigned integer) and a table of coefficients, "polyn". 
The coefficient of the highest order term of the 
polynomial is addressed by "polyn" . All coefficients 
are stored consecutively in memory. The algorithm 
below is intended to define the value desired, not 
the precise sequence in which the calculations are 
actually performed. 



X := operand; Y := 0; C := 0; 
MOVEADR polyn, Lcoeff; 
while C < degree do 

Y := Y * X + (Lcoeff+C*t)[0. 
operand := Y; 



.8*t-l]; 



P0LY4F 
Status: FlFlags 
Traps: AddressingV 

FlArith 



P0LY8F P0LY16F 

FlFlags FlFlags 

AddressingV AddressingV 

FlArith FlArith 
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6.2.3 Logical Operations and Shifts 


6.2.3.6 LSRt shiftcount.rl, bitfield.ru 




Logical shift right. "Bitfield" is shifted right by "shiftcount" 




bits and the result is stored back in "bitfield". 


6.2.3.1 AND4 mask,r4, operand, rw4 


Zeros are shifted into the most significant bit; bits 




shifted out of the least significant bits are lost. 


Logical AND. The bit-wise logical AND of "mask" and "operand" 


For interpretation of "shiftcount", see LSLt. 


is computed and the result is stored in "operand". 






includes: LSR4 LSR8 


6.2.3.2 N0T4 source. r4, destination.u4 


6.2.3.7 ASLt shiftcount.rl, operand. rw 


Logical NOT. The bit-wise logical NOT (one's complement) of 


Arithmetic shift left. "Operand" is shifted left by "shiftcount" 


"source" is computed and the result is stored in 


bits and the result is stored back into "operand". 


"destination". 


Zeros are shifted into the least significant bit; bits 




shifted out of the most significant bit are lost. 




Overflow occurs if the new sign bit or any of the bits 




shifted out are different from the original sign bit. 




For interpretation of "shiftcount", see LSLt. 


6.2.3.3 0R4 mask.r4, operand. nii4 




Logical OR. The bit-wise (inclusive) OR of "mask" and "operand" 


ASL4 ASL8 


is computed and the result is stored in "operand". 


Traps: Ovfl Ovfl 




6.2.3.8 QUAD4 source. r4, destination. w4 


6.2.3.4 X0R4 mask.r4, operand. rw4 






Quadruple, "dest" is given the value of "source" times four. 


Exclusive OR. The bit-wise exclusive OR of "mask" and "operand" 




is computed and the result is stored in "operand". 


M0VE4 source, destination; 




ASL4 2, destination; 




Traps: Ovfl 


6.2.3.5 LSLt shiftcount.rl, bitfield. rw 




Logical shift left. "Bitfield" is shifted left by "shiftcount" 




bits and the result is stored back in "bitfield". 


6.2.3.9 ASRt shiftcount.rl, operand. rw 


Zeros are shifted into the least significant bit; bits 




shifted out of the most significant bits are lost. 


Arithmetic shift right. Divide the integer value of "operand" 


"Shiftcount" is unsigned; only the rightmost 5 bits 


by 2**shiftcount, truncating toward zero and store 


(for LSL4) or 6 bits (for LSL8) are significant. 


the result back into "operand". See LSLt for 




interpretation of "shiftcount". 




Note: for negative values of "operand" this is not 


includes: LSL4 LSL8 


the same as a straight sign-propagating right shift. 




includes: ASR4 ASR8 
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6.2,4 Compares and Tests 



6.2.4.1 CMPt sourcel.r, source2.r 

Compare. The condition code CC is set depending on the result o 
the comparison of the values of "sourcel" and "source2". 
For CMP2, CMP4 and CMP8 a two's complement compare is 
performed; for CMPl an unsigned integer compare is 
performed. For CMP4F, CMP8F and CMP16F comparison is 
performed according to the IEEE floating point standard; 
note that this can result in "unordered". 
Condition codes are set as follows: 

CCG, if sourcel > source2 

CCE, if sourcel = source2 

CCL, if sourcel < source2 

ecu, if sources are "unordered" (IEEE only) 



CMPl 


CMP2 


CMP4 


CMP8 


CMP4F CMP8F CMP16F 


CC 


CC 


CC 


CC 


CC CC CC 
FlFlags FlFlags FlFlags 
FlArith FlArith FlArith 



Status: 
Traps: 



6.2.4.2 TESTt source. r 

Compare to zero. This instruction is merely a short form of 
^CMPt source, 0'. 



TESTl TEST2 TEST4 TESTS TEST4F TEST8F TEST16F 
Status: CC CC CC CC CC CC CC 

FlFlags FlFlags FlFlags 
Traps: FlArith FlArith FlArith 
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6.2.4.3 CMPC length. r4, stringa.m, stringb.m, index. ¥4 

Counted Compare. This instruction compares two streams of bytes 
"stringa" and "stringb" until the first non-equal byte 
has been encountered or until "length" bytes have been 
compared. The condition code in STATUSB is set depending 
on the unsigned compare of the last pair of bytes examined. 
"Index" is set to the number of the first non-equal byte. 
If interrupted, the number of bytes left to compare is 
pushed onto the stack and the instruction- in-progress 
flag is set. 



MOVEADR stringa, Ala; 

MOVEADR stringb, Bla; 

if IIP = then C := 

else P0P4 C; 

IIP := 0; 

while C < length and 

(Ala+C)[0..7] = (Bla+C)t0..7] 
do begin 

C := C + 1; 

{if implementation chooses to acknowledge 
external interrupts here, then 
PUSH4 C and set IIP := 1 } 

end; 
if C >= length then CC := CCE 
else if (Ala+C)[0..7] > (Bla+C) [0, .7] then CC 
else CC := CCL; 
index := C; 



CCG 



Status: CC 

Traps : Address ingV 
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6.2.4.4 TESTLSB source. rl 

Test least significant bit. The condition code is set to CCG 
if the least significant bit of "source" is 1, 
otheriflise the condition code is set to CCE. 

Byte[0..7] := source; 

if byte [7] = 1 then CC := CCG 

else CC := CCE; 

Status: CC 



6.2.4.5 TESTOV 

Test overflow. The condition code is set to CCG if the overflow 
exception flag is set, else the condition code is set 
to CCE. The overflow flag is left clear. 

if STATUSB.OVr = 1 then CC := CCG 
else CC := CCE; 
STATUSB.OVF := 0: 



Status: 



CC 
Overflow 



6.2.4.6 TESTA 

Test conditional break enable. If the "CBA" trap is enabled, 
set the condition code to CCG, otherwise to CCE. 



if STATUSB.CBA 
else CC := CCE; 



1 then CC := CCG 



Status: CC 



6.2.4.7 TESTB 



Test conditional break enable. If the "CBB" trap is enabled, 
set the condition code to CCG, otherwise to CCE. 

if STATUSB.CBB = 1 then CC := CCG 
else CC := CCE; 

Status: CC 
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6.2.4.8 TESTBIT bitindex.r4, bitarray.mr 

Test a bit. The condition code is set depending on the value of 
a bit in a bit array at the index "bitindex". The bit 
array must be in memory (it cannot be in a register) and 
its first byte must be addressed by "bitarray". If the 
bit is found set, the condition code is set to CCG, else 
it is set to CCE. 

MOVEADR bitarray, Addr; 

Bytela[0..31] := Addr [0.. 31]; 

Byte_index[0. .31] := bitindex [0.. 28]; {sign-extend} 

Bytela[32..63] := Addr[32..63] + Byte_index; 

Byte := (Bytela) [0. .7]; 

Bit_num := bitindex [29. .31] ; 

if Byte [Bit num] = 1 then CC := CCG else CC ;= CCE; 



Status: 
Traps: 



CC 
Address ingV 



6.2.4.9 SCANUNTIL charset.mr, string. mr, index. rw4 

Scan string until condition satisfied. The string of characters 
(bytes) pointed to by "string" is scanned for a character 
that satisfies a particular condition. "Index" must be 
initialized by software; SCANUNTIL increments "index" 
(ignoring any overflow) continually as the search proceeds. 
The condition to be satisfied by the character is encoded 
as a 256-bit bit array (similar to a Pascal set) . 
Bits found set in the bit array "charset" signify that 
the corresponding character satisfies the condition. 
If the logical address of "charset" is at or within 32 
bytes of the object's upper bound, an addressing violation 
trap is raised. This instruction must be inter ruptible; 
"index" contains sufficient information to restart. 

MOVEADR string, St; 

index := index - 1; 

repeat index := index + !• 

Char := (St+index) [0. .7]; {zero-extend} 

{implementations may choose to 
acknowledge an interrupt here} 

TESTBIT Char, charset; {charset [Char] } 

until CC = CCG; { =1 } 



Status: 
Traps: 



CC NOT affected 
Address ingV 
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6.2.4.10 CMPB fillchar, Igtha, srca, Igthb, srcb, index 


6.2.5 Base Register Instructions 


CMPB fillchar. rl, Igtha. r4, srca.mr, Igthb. r4, srcb.mr, index. w4 




Compare bytes. "Srca" is compared to "srcb" and the condition 


6,2.5.1 BGET8 source. b, destination. w8 


code set. The shorted string is considered padded with 




"fillchar". "Index" identifies the offset where bytes 


Get address in base register. See under "MOVEADR". 


started to differ. CCG and CCL refer to the unsigned 




compare fo the bytes at that location. 






6.2.5.2 BSET8 source. rS, dest.b 


C := 0; Flag := 1; 




MOVEADR srca, La; 


Set base register to logical address. Load the 64-bit logical 


MOVEADR srcb, Lb; 


address from "source" into the designated beise register. 


while ( C < Igtha or 


The logical object id of the logical address must be 


C < Igthb and 


valid. The logical offset of the logical address need 


Flag = 1 ) do begin 


not be within object bounds. 


A := fillchar; B := fillchar* 

if C < Igtha then A := (La+C) [0. .7]; 






if C < Igthb then B := (Lb+C) [0..7]; 


j := base_reg_designator_of (dest); 


if A <> B then begin 


if j >= 6 then Trap"Opnd"' 
Bj[0..63] := source [0.. 63] ; 


if A > B then CC : = CCG 


else CC := CCL; 


Group := source [0.. 2]- 
Object: = source[3..31j; 


Flag := 0; 


end; 


if Object*16 > length_of_ODT_of (Group) 


end; 


then Trap" AddressingV" ; 


if Flag = 1 then CC := CCE; 




index := C; 






Traps: AddressingV 


Status: CC 




Traps: AddressingV 






6.2.5.3 BMOVEADR source. n, dest.b 




Move logical address to base register. This instruction is like 


6.2.4.11 CMPT table, fillchar, Igtha, srca, Igthb, srcb, index 


MOVEADR, but the result is stored in the base register 




designated by "dest". This instruction doubles as a 


CMPT table. mr, fillchar. rl, Igtha. r4, srca.mr, Igthb. r4. 


base-register- to-base-register move. An assembler 


srcb.mr, index. w4 


language alias "BM0VE8" is provided for this usage. 


Compare bytes, translated. This instruction resembles CMPB 




except in that compares are made of the bytes in 


MOVEADR source, Temp; 


"table" indexed by the data bytes in the strings 


BSET8 Temp, dest; 


rather than of the actual data bytes themselves. 






Traps: AddressingV 


Status: CC 




Traps: AddressingV 
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6.2.5.4 BM0VE8 source. b, dest.b 


6.2.5,9 BADD4 tenii.r4, dest.b 


Move base to base register. See under "BMOVEADR". 
6.2.5.5 BGET4 source. b, dest.u4 


Add to offset of base register. The 32-bit value "term" is 
added to the logical address in the base register 
designated by "dest" using wrap-around 32-bit 
arithmetic. Overflow and carry is ignored. 


Get offset of base register. Store 32-bit logical offset of the 
base register designated by "source" into "dest", 
"Source" must be a memory operand, according to the ".b" 
attribute. 


j := base reg designator of (dest); 
if j >= 6 then Trap"Opnd"; 
Bj[32..63] := Bj[32..63] + term; 


j := base reg designator of (source); 
dest := Bj[32..63]; 

6.2.5.6 BSET4 source. r4, dest.b 


6.2.5.10 BSUB4 term.r4, dest.b 

Subtraict from offset of base register. The 32-bit value "term" 
is subtracted from the logical address in the base 
register designated by "dest" using wrap-around 32-bit 
arithmetic. Overflow and carry is ignored. 


Set offset of base register. Load "source" into the 32-bit 
logical offset of the designated base register. 


NEG4 term, Temp; 
BADD4 Temp, dest; 


j := base reg designator of (dest); 
if j >= 6 then Trap"Opnd"; 
Bj[32..63] := source [0.. 31]; 


6.2.5.11 BCMP4 sourcea.b, sourceb.r4 


6.2.5.7 BPUSH8 source. b 

Push a base register. See under "PUSHADR". 


Compare offset of base register. The 32-bit offset of the base 
register designated by "sourcea" is compared using two's 
complement arithmetic with the value of "sourceb". 
Condition codes are set to reflect the result of the 
comparison. No overflow can occur. 


6.2.5.8 BP0P8 dest.b 

Pop into a base register. Eight bytes are popped off the stack 
and loaded into the designated base register. 


j := base reg_designator_of (sourcea); 
if bT[32.,63] > sourceb then CC := CCG 
else if Bj[32..63] = sourceb then CC := CCE 
else CC := CCL; 


POPS Temp; 
BSET8 Temp, dest; 


Status: CC 


Traps: AddressingV 
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6.2.5.12 BCMP8 sourcea.b, sourceb.rS 

Compare base register with logical address. The 64-bit logical 
address in the base register designated by "sourcea" is 
compared for equality with the logical address in 
"sourceb". If the two logicl addresses are equal, CCE 
is set; otherwise, implementations may set either COG or 
CCL arbitrarely. 



j := base_reg_designator_of (sourcea); 
if Bj[0..63] = sourceb then CC := CCE 
else CC := CCG {or CCL}; 



Status: CC 



6.2.5.13 BTEST8 source. b 



Test base register for NIL. The base register designated by 

"source" is compared to a logical address of all zeros. 



BCMP8 source, 0: 



Status: CC 
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6.2.6 Transfer of Control 



6.2.6.1 BR{GLEU} target. r4 

Branch. Depending on the match between the condition code field 
in the status register and the mask comprised of four 
bits in the opcode, execution continues with either the 
next instruction in sequence or with the instruction 
explicitly designated by "target". If a match is found 
then the branch is taken. The target address of the 
branch is found by adding "target"*2 to the value of P 
P at the beginning of the branch instruction itself. 
If the branch is not taken, and the target is in any 
way illegal, implementations may differ in whether an 
Opnd trap is raised on "target". 



mask[0] := 1- OPCODE [3]; mask [3] := OPCODE [4]; 

mask[1..2] := 0PC0DE[6. .7]; 

if CC=CCU and Unordered_trap enabled 

and ( mask[0]=l or mask_l]=l ) 
then Trap" Invalid Operation"; 
if mask[0] = 1 and CC = CCG 

or maskil] = 1 and CC = CCL 

or mask [2] = 1 and CC = CCE 

or mask [3] = 1 and CC = CCU 
then P := P + target * 2; 



Instruction Mnemonic 
Branch Never BRN 
Branch Unordered BRU 
Branch Equal ORE 

Branch Equal or Unord BREU 
Branch Less BRL 

Branch Less or Unord BRLU 
Branch Less or Equal BRLE 
Branch Not Greater BRNG 
Branch Greater BRG 
Branch Greater or Unord BRGU 
Branch Greater or Equal BRGE 
Branch Not Less BRNL 
Branch Greater or Less BRGL 
Branch Not Equal BRNE 
Branch Not Unordered BRNU 
Branch Always BR 

Traps: CODEBNDSV 
FLINV 



Assembler aliases 



BRZ BREVEN BRNOV 

BRZU 

BRM 

BRMZ 

BRLEU 

BRP BRODD BROV BRBUSY 

BRPZ 
BRGEU 

BRGLU 
6RGLE 
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6.2.6.2 CALL target. r4 


6.2.6.4 BRX loi.r4 


Procedure call. A procedure marker is pushed onto the stack 


External Branch. Control is transferred to the target 


and control is passed to "target", interpreted as 


indicated in the OD for "loi". Loi contains the 


a 32-bit half-niord offset relative to the start of 


high 32 bits of a logical address into the target 


the CALL instruction. CALL requires the procedure 


code object. 


to be within the current code object. 






IIP := 1-IIP; if IIP=1 and PTE=1 then Trap"DBCALL"; 


IIP := 1-IIP; if IIP=1 and PTE=1 then Trap" DBCALL"; 


IIP := 0; 


S := S + 4; {pushes garbage} 


Ptarget [0.. 31] := loi; 


PUSH4 P[32..63],- 


Ptarget [32.. 61] ;= 0D( loi). EPUO; 


PUSH4 Q[32..63]; 


Ptarget [52.. 63] := 0; 


Q := S; 


if OD(loi).TyP <> VisionCode then Trap" CODETYPV"; 


P := P + target * 2; 


if STATUSA. XL > OD(loi).PR 




or STATUSA. XL > OD(loi).XL 




then Trap"CODERINGV"; 


Traps: STKOVF 


if (Q-8) [0] = then begin 


CODEBNDSV 


(Q-8)[0] := 1; 


DBCALL 


(Q-8)[1..2] := STATUSA. XL; 




(Q-12)[0..31] := P[0..31]; 




end; 


6.2.6.3 CALLX loi.r4 


P := Ptarget; 


EKternal call. A procedure marker is pushed onto the stack and 




control is passed to the entry point specified in the 


Traps: CODETYPV 


OD for "loi". "Loi" contains the high 32 bits of a 


CODERINGtV 


logical address into the target object. 


CODEBNDSV 




DBCALL 


IIP := 1-IIP; if IIP=1 and PTE=1 then Trap"DBCALL"; 




IIP := 0; 




PUSH8 Preturn; 




(S-4)[0..6] := STATUSA; 




PUSH4 Q[32..63]; 

Q := S; 

if OD(loi).TYP <> VisionCode then Trap"CODEi:YPV"; 






if STATUSA. XL > OD(loi).PR then Trap"CODERINGV"; 




STATUSA. XL := OD(loi).XL; 




Ptarget[ 0..31] := loi; 




Ptarget[32..61] := OD(loi) .EPUO; 




Ptarget[62..63] := 0; 




P := Ptarget; 




Traps: STKOVF 




CODETYPV 




CODEBNDSV 




CODERNGV 




DBCALL 
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6.2.6.5 EXIT 


6,2.6.6 SEXIT 


EKit from procedure. This instruction can be used to return 


Subroutine exit. This instruction can be used to return from a 


from a procedure called with CALL or CALLX. The 


subroutine called with a PUSH4; BR combination. 


procedure marker located at Q contains the necessary 


The value of Q is not affected. 


information to restore the context of the caller. 




If the caller executed in a different code object 


P0P4 Returnoffs* 

if Returnoffs [31 J = 1 and {implementation 


than the current one, a number of checks are made. 




chooses to detect this condition} 




then Trap" INSODDP"; 


if (Q-8)[0] = 1 then begin 


Returnoffs [31] := 0; 


{external exit} 


P[32..63] := Returnoffs; 


Pobject := (Q-12) [0. .31]; 




Poffset := (Q-8)[8..31], zero-extended; 
ST return := (Q-8)[0..7]; 




Traps: STKUNF 


if STATUS. XL > 0D( Pobject) .XL 


CODEBNDSV 


then Trap"STKCONSISTV"; 


INSODDP 


if ST return. XL > STATUSB.XTL 




then Trap" INSXTL"; 




end 




else begin 


6.2.6.7 BREAK parameter. r4 


{internal exit} 




Pobject := P[0.,31]; 


Breakpoint. This instruction always causes a breakpoint trap. 


Poffset := (Q-8)[0..3l3; 


The value of STATUSD.DRL has no effect. 


ST_return := STATUSA; 




end; 




Q offset := (Q-4)[0.,31]; 


Trap"DBBREAKINS"; 


if Q offset < or Q offset > Q[32..63] - 12 




then Trap"STKCONSISIV"; 




if Poffset[31] = 1 


Traps: DBBREAKINS 


and (implementation chooses to detect this) 




then Trap" INSODDP"; 




Poffset [31] 


= 0; 




S[32..63] 


= Q[32..63] - 12; 


6.2.6.8 ERROR 


Q[32..63] 


= Q_offset; 




P[0.,31] 


= Pobject; 


Error. This instruction always causes a trap for all users. 


P[32..63] 


= Poffset; 




STATUSA 


= ST return; {SIT bit not to 




take effect until 


Trap"INSERROR"; 


next instruction} 






Traps: INSERROR 


Status: restored from marker on external exit 




Traps: INSXTL 




STKCONSISTV 


6.2.6.9 NOP 


CODEBNDSV 




INSODDP 


No operation. Continues with the immediately following 




instruction. 
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6,2,6.10 CHECKA parameter , r4 

Conditional break. If the "CBA" enable bit is set, a trap is 
taken. If "CBA" is disabled, no Opnd trap should be 
raised even if "parameter" is somehow illegal; insteaui 
"parameter" should be ignored. 



if STATUSB,CBA = 1 then Trap"DBCHECKA"; 
Traps: DBCHECKA 

6.2.6.11 CHECKB parameter, r4 

Conditonal break. If the "CBB" enable bit is set, a trap is 
taken. If "CBB" is disabled, no Opnd trap should be 
raised even if "parameter" is somehou illegal; instead 
"parameter" should be ignored. 

if STATUSB.CBB = 1 then Trap"DBCHECKB"; 
Traps: DBCHECKB 

6.2.5.12 CHECKLO source. r4, lobound.r4 

Check lower bound. If "source" is less than "lobound", a 

bounds check trap occurs. The comparison is a two's 
complement 32-bit compare. 

if source < lobound then Trap"INSCHKLO"; 
Traps: INSCHKLO 

6.2.6.13 CHECKHI source, r4, hibound,r4 

Check upper bound. If "source" is greater than "hibound", a 
bounds check trap occurs. The comparison is a two's 
complement 32-bit compare. 

if source > hibound then Trap"INSCHKHr'; 
Traps: INSCHKHI 
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6.2.7 Interaction with Machine State 



6.2.7.1 M0VEfSP4 selector. rl, destination. w4 

Move from special register. This selects a certain register 
or dedicated memory location based on the value of 
"selector". This register or memory location is then 
right justified, zero filled and stored in the 32-bit 
"destination". An INSMOVSPL violation occurs when 
either the value of the selector does not correspond 
to any entry in the following list or when the current 
execute level does not match the level required for 
reading the selected register. 



selector 



#bits req'd XL Assembler alias 



condition code 


2 


3 


GetCC 


1 rounding mode 


2 


3 


GetRM 


2 exit threshold 


2 


3 


GetXTL 


3 execute level 


2 


3 


GetXL 


4 flpt trap enable 


5 


3 


GetTEFLP 


5 int trap enable 


2 


3 


GetTEINT 


6 dec trap enable 


2 


3 


GetTEDEC 


7 flpt mode 


2 


3 


GetFPCMODE 


8 STATUSA 


32 


3 


GetSIATA 


9 STATUSBl 


32 


3 


GetSTATBl 


10 STATUSB2 


32 


3 


GetSTATB2 


11 TRYoffset 


32 


3 


GetTRY 


12 cond break A 


1 




GetCBA 


13 cond break B 


1 




GetCBB 


14 task clock enable 


1 




GetTCE 


15 STATUSCl 


32 




GetSTATCl 


16 Interrupt Mask 


16 




GetlMR 


17 STATUSD 


32 




GetSTATD 


22 HASH. PA 


32 






23 HASH. LENGTH 


32 






24 PDIR.PA 


32 






25 PDIR, LENGTH 


32 







Traps: INSMOVSPL 
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6.2.7.2 M0VEtSP4 selector. rl, source. r4 

Move to special register. This instruction selects a special 
hardware register or dedicated memory location 
based on the value of "selector". The value of 
"source" is stored into this register or location. 
The least significant bits of "source" are used in 
the assignment, without any overflow indication. 
A trap is taken when the selector does not match 
any of the entries in the following table or if 
the current ring level does not match the required 
ring level. 



07/31 



selector 



#bits req'd XL Assembler Alias 



condition code 

1 rounding mode 

2 exit threshold 

3 flpt trap enable 

4 int trap enable 

5 dec trap enable 

6 flpt mode 

7 STATUSB2 

8 Q_offset 

9 task breakrange LOI 

10 cond break A 

11 cond break B 

12 task clock enable 

13 Interrupt mask 

14 Debug ring level 

15 sys breakrange LOI 



Status: depends on selector 
Traps: depends on selector 

Opnd 

INSMOVSPL 

STKCONSISTV (if setting Q offset to value 
outside SB and S) 



2 


3 


SetCC 


2 


3 


SetRM 


2 


< source 


SetXTL 


5 


3 


SetTEFLP 


2 


3 


SetTEINT 


2 


3 


SetTEDEC 


3 


3 


SetFPCMODE 


32 


3 


SetSTATB2 


32 


3 


SetQ 


32 


3 


SetTBR 


1 


1 


SetCBA 


1 


1 


SetCBB 


1 





SetTCE 


16 





SetlMR 


2 





SetDRL 


32 





SetSBR 
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6.2.7.3 MOVEfSPS selector. rl, destinaiton.wS 

Move from special register. This instruction is used to 

obtain the contents of a special hardware register 
or dedicated memory location identified by the 
value of "selector". Values of "selector" not 
represented in the following list cause the trap 
"INSMOVSPL" to be raised. 
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selector 


#bits 


req'd 


XL 


Assembler Alias 


program counter 


64 


3 




GetP 


1 ODTO.LA 


64 








2 TCB.LA 


64 






GetTCB 


3 TCBX.LA 


64 






GetTCBX 


4 interval timer 


64 








5 task clock 


64 








6 time of century 


64 








7 QI.LA 


64 









Traps: INSMOVSPL 



6.2.7.4 MOVEtSPS selector. rl, source. r8 

Move to special register. This instruction stores the 
value of "source" into the special hardware 
register or dedicated memory location identified 
by "selector". 



selector 



#bits req'd XL Assembler Alias 



TCBX.LA 


64 . 





1 interval timer 


64 





2 task clock 


64 





3 time of century 


64 





4 QI.LA 


64 





5 DST descriptor 


64 





6 CST descriptor 


64 






SetTCBX 



Traps: 



dependent on selector 
INSMOVSPL 
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6.2.7.5 TRY 

Mark the stack with the TRYoffset. Uhen paired with UNTRY, 
TRY supports the try/recover construct of MODCAL. 
The old value of TRYoffset is pushed onto the stack 
and the current value Of S is recorded in TRYoffset 
(hence TRYoffset points to the location in the stack 
where the previous value of TRYoffset is kept). 
UNTRY is used to undo this sequence. The hack chain 
of TRYoffsets is much like the back chain of Qoffsets 
but under total software control independent of CALL/ 
CALLX. TRY must not be executed on the ICS. 



if STATUSC.ICS = 1 then Trap "TRYV"; 
PUSH4 TRYoffset; 
TRYoffset := S[32..63]; 
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Traps: STKOVF 
TRYV 



6.2.7.6 UNTRY destination. w4 

Remove one TRY marker. This instruction undoes the action 
performed by TRY. This causes the previous value 
of TRYoffset to become reestablished. UNTRY must 
not be executed when on the ICS. Note that the 
TRYoffset need not be on top of the stack when 
UNTRY is executed, nor is it popped off. 



if STATUSC.ICS = 1 then Trap"TRYV"; 



Temp [32.. 63] 
destination 
Temp [0.. 31] 
TRYoffset 



= TRYoffset; 

= TRYoffset - 4; 

= S[0..31]; 

= (Temp - 4)[0..3l]; 



Traps: TRYV 

AddressingV 
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6.2.8 Instructions that interact with the address space 



6.2.8.1 PROBE ring.rl, access. rl, address. r8j Xengtll,r4 

Probe access rights. This instruction sets condition codes 
dependent on the legality of accessing the address 
range given by "address" and "length". PROBE tests 
whether in the ring level specified by "ring" the type 
of access represented by "access" would be legal 
everywhere in the logical address range starting at 
"address" and ending at "address"*" length"- 1. 
Here a negative "length" is treated as 0. 
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Encodings: 


1 
2 
3 
4 



ring 


1 
2 
3 
caller's 



access 

memory_read 
memoryjiirite 
instruction fetch 



Values not in the list above will cause an INSPROBE 
trap. 

The resulting conditon code settings are as follows: 
CCL: the object does not exist or the indicated 
access is illegal. 

CCE: the indicated access is legal but the indicated 
address range is not wholly within the object. 

CCG: the indicated access is legal at the indicated 
privilege level over the entire address range 
specified. 



Status: CC 
Traps: INSPROBE 
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6.2.8.2 TESTREF ppn.r4 

Test reference bit. Returns the state of the reference bit for 
the physical page "ppn" in the condition codes and 
then clears the reference bit. "Ppn" gives the physical 
page number. If the reference bit in the PPD for the 
page is found set, then CCG is returned, otherwise CCE. 

The reference bit in the PPD is then cleared. 

Any address translation aid (TLB) must synchronize 

itself with the contents of the PPD as part of the 

execution of TESTREF. 

Note that TESTREF only provides a snapshot: immediately 

after executing TESTREF some other processor may access 

the page; this would not be reflected in the condition 

codes . 

Ring privilege is required. 



Status: 
Traps: 



CC 
INSPRIV 
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6,2.8,3 PDINS ppn,r4 

Insert page into PDIR, This instruction takes the Physical Page 
Descriptor (PPD) identified by the physical page number 
"ppn" and inserts it in the proper Hash chain. The PPD 
must be entirely initialized before using this instruction, 
except for the link field. The Virtual Page Number (VPN) 
in the PPD itself is used to compute the hash value H that 
locates the proper chain. The PPD will be inserted as the 
first link in the chain. No other PPDs in the PDIR will 
be changed. If the PPD for "ppn" is already linked into 
a hash chain before PDINS is executed, the results are 
undefined. PDINS requires ring privilege. 



if XL > then Trap" INSPRIV"; 

PPDpa := PDIR. PA + 16 * ppn; 

Pp : = ( PPDpa) [ 1 , . 20 ] ; { zero-extend } 

if ppn <> Pp then Trap"ADRPDIR"; 

VPN := (PPDpa + 4 )[0.,51]; 

Bucketpa := HASH, PA + 4 * hash( VPN ); 

Link := (Bucketpa) [0,. 31]; 

(PPDpa + 12)[0,.31] := Link; 

(Bucketpa) [0.. 31] := PPDpa; 



Note: the bracketed portion must be synchronized with 
other hardware access to the hash bucket in a 
shared-memory multi-processor system. 
Such a system may use bit of the hash bucket 
(Bucketpa) [0] as a semaphore bit. 
This bit must be returned to 0. 
See PDDEL for further detail. 



Traps: 



INSPRIV 
ADRPDIR 
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6.2.8.4 PDDEL ppn.r4 

Delete from PDIR. The Physical Page Descriptor PPD for the 
physical page with physical page number "ppn" is 
removed from its hash chain. 
Ring privilege is required. 

PPDpa := PDIR. PA + 16 * ppn; 

VPN := (PPDpa + 4)[0..51]; 

Linkpa := HASH. PA + 4 * hash( VPN ); 

repeat 

Oldlirikpa := Lirikpa; 

Linkpa := (Linkpa + 12)[0..31]; 

if Linkpa = then Trap"ADRPDIR"; 

until Linkpa = PPDpa; 
(01dlinkpa+12)[0..31] := (PPDpa+12) [0. .31] ; 
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Notes: 



(consult carefully when implementing a VISION machine 
capable of running as a shared-memory multi-processor) 



1) Address translation aids (TLB) must be synchronized (by 
hardware) with the state of the PDIR/HASH before hardware 
may execute the instruction following PDDEL. 

2) In a shared-memory multi-processor system, implementations 
must guarantee that read-write operands never fault on the 
write. The burden for ensuring this can be placed entirely 
on the implementation of PDDEL. This requires PDDEL to 
complete a handshake with all processors in the system 
before the instruction following PDDEL executes. 

3) Various functions compete for access to hash bucket and PPDs 
and these functions must be carefully synchronized by 
hardware. These functions are: address translation; writing 
dirty/reference bits; PDINS; TESTREF; PDDEL. 

Each hash bucket and each PPD has a bit for semaphore use by 
hardware. It is sufficient to lock the appropriate hash 
bucket for the entire duration of each function. However, 
doing so might add overhead to writing dirty/reference bits. 
The following scheme is also sufficient: when writing dirty/ 
reference bits lock only the PPD; when translating addresses 
lock hash bucket and each PPD in the chain and unlock each 
immediately after reading its contents; PDINS locks the hash 
bucket; PDDEL locks two consecutive links in the chain 
(starting with the hash bucket) and unlocks the first one 
only after it has obtained the lock for the third one. 
Hardware must unlock all semaphores when a trap occurs. 

Traps: ADRPDIR 
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6.2,8.5 CVLAtVA operand. il, virtaddr.wS 

Convert logical address to virtual address. The virtual 
address corresponding to the logical address of 
"operand" is computed and stored in "virtaddr" . 
Level 1 privilege is required. The reference 
bit for the page containing "operand" is not 
affected. 



Traps: 



INSPRIV 



6.2.8.6 HASH virtaddr. r8, hashindex.w4 

Hash address. The 64-bit virtual address "virtaddr" is 
converted to a hash index which is stored in 
the 32-bit "hashindex". Level 1 privilege is 
required. Bits 52.. 63 of "virtaddr" are ignored. 



Traps: 



INSPRIV 



6.2.8.7 CWAtPP virtaddr. r8, ppn.u4 

Convert virtual address to physical page number. The 64-bit 
"virtaddr" is translated to find the physical page 
on which it resides. It returns a 20-bit physical 
page number, right justified and zero-extended. 
However, if the page is absent, "ppn" is set to -1. 
Level privilege is required. The reference bit 
for the addressed page is not affected. 

VPN := virtaddr [0.. 51]; 

if page VPN is currently present then 

ppn := physicalj?age_number_of_(VPN) 
else 

ppn := -1; 



Traps: 



INSPRIV 
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6.2.8.8 GrowGDO newlength.r4 


6.2.9 Instructions for Tasking and Synchronization 




Grow group zero ODT. This instruction informs hardware that 






the length of the Object Descriptor Table for group zero 






has been increased. The Group Descriptor for group zero 


6.2.9,1 DISABLE oldi.wl 




is updated to reflect this, in all processors in a 






shared-memory multi-processor system. Ring privilege 


Disable interrupts. 




is required. It is the responsibility of operating 






system software to ensure that the newly addressable ODs 


if STATUSA.XL > 1 then Trap; 




in group zero are properly initialized. 


oldi := STATUSC.IE; 
STATUSC.IE := 0; 




if STATUSA.XL > then Trap" INSPRIV" ; 






if GDO.UB < GDO.LB + new length 


Traps: INSPRIV 




then GDO.UB := GDO.LB + new length; 






Traps: INSPRIV 


6.2.9.2 ENABLE oldi.rl 

Enable interrupts. 

if STATUSA.XL > 1 then Trap; 
STATUSC.IE := oldi; 

Traps: INSPRIV 

6.2.9.3 INTERRUPT pr.r4 

Cause processor interrupt at priority "pr". 

if STATUSA.XL > then Trap; 

pri := pr[28..31]; 

IPR[ pri, processor ] := set; 

Traps: INSPRIV 
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6.2.9.4 PSDB 


6.2.9.6 DISP 


Pseudo Interrupt Disable. The Dispatcher Disable Count (DDC) is 


Dispatch. This instruction is used to enter the dispatcher as 


incremented. This inhibits dispatching of new tasks. 


soon as is practicable. The only way to enter the 


It does not disable external interrupts. The PSDB/PSEB 


dispatcher is through this instruction. 


pair can be used as a very efficient way to protect 


If the dispatcher cannot be entered right away, the 


critical regions in a uni-processor system. PSDB/PSEB 


Dispatch Request Flag is set. Ring 1 privilege is 


pairs can be nested. Ring 1 privilege is required. 


required. The following conditions must hold before 




the dispatcher can be entered: 


if XL > 1 then Trap"INSPRIV"; 




if DDC < then Trap"INSDDCV"; 


/ STATUSC.DDC = 


if DDC > 2**27-l then Trap"INSDDCV"; 


1 STATUSC.XM = 


DDC := DDC + 1; 


1 STATUSC.ICS = 




\ STATUSC.IE = 1 


Traps: INSPRIV 


if XL > 1 then Trap" INSPRIV"; 


INSDDCV 


if STATUSCl = 1 or STATUSCl = 3 then begin 




PUSH INTERRUPT MARKER; TCB.SN := S; 




STATUSC.ICS := 1; STATUSC. DRF := 0; 




execute_case_2_of _I EXIT ; 


6.2.9.5 PSEB 


end 




else 


Pseudo Interrupt Enable. This instruction removes one inhibition 


STATUSC. DRF := 1; 


on dispatching new tasks and so undoes the effect of the 




most recent PSDB. PSEB requires ring 1 privilege. 


Status: either unchanged or loaded from Dispatcher marker 


If a dispatch request is pending (DRF = 1), conditions 


Traps: INSPRIV 


for entering the dispatcher are checked and an attempt 


STKOVF 


is made to enter the dispatcher. These conditions must 




be satisfied before the dispatcher can be entered: 




STATUSC.DDC = 


6.2.9,7 LAUNCH tcbla.rB, tcbva.rS 


STATUSC.XM = 




STATUSC.ICS = 


Launch a task. This instruction is used by the dispatcher to 


STATUSC.DRF = 1 


start execution of the task identified by "tcbla" and 


STATUSC.IE = 1 


"tcbva". The new current TCB is located at "tcbla" in 




logical address space and at "tcbva" in virtual address 


The PSDB/PSEB can also be used to protect regions within 


space. It is the responsibility of operating system 


the dispatcher code itself; in this case the OFF flag 


software to ensure that "tcbla" and "tcbva" are indeed 


must be ignored. 


logical and virtual address to one and the same task 




control block. Level privilege is required. 


if XL > 1 then Trap" INSPRIV"; 




if DDC <= then Trap" INSDDCV"; 


if STATUSC. ICS=0 then Trap" INSPRIV"; 


DDC := DDC - 1; 


if Q <> QI then Trap"STKCONSISTV"; 


if STATUSC = 3 then DISP 


TCB. LA := tcbla; TCB.VA := tcbva; 


else if STATUSC = 7 then begin 


GDI := TCB. GDI; 


if STATUSB.DISP = 1 then DRF := 0; 




end 


GD7 := TCB.*GD7; 




execute_case_l_of _I EXIT ; 


Traps: INSPRIV 




INSDDCV 


Traps: INSPRIV 




SIKCONSISTV 
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6.2.9.8 lEXIT 

Interrupt Exit. This is used at completion of an interrupt 

handler (either external or internal) . A trap occurs 
if the instruction is executed other than on the ICS. 
Q must either point to the dispatcher marlter or to an 
interrupt marker, otherwise results are unpredictable. 
If any of the pages of the ICS are absent, results are 
unpredictable. If lEXIT returns control to a task, the 
TCB of that task must be resident. If any pages on the 
task's stack containing the interrupt marker are absent, 
or if that stack is in a stack overflow condition, the 
appropriate trap is taken which runs as the bottom 
routine on the ICS (at QI). Neither TCB nor the task 
stack object are modified in any way. There are three 
cases of lEXIT which are sorted as follows: 

Case 1: I EXIT should return control to a task without 
involving the dispatcher. 

This case obtains if Q=QI, while DRF=0 or dispatching 
is otherwise disabled. 

Case 2: I EXIT should run the dispatcher to have it select 
a task to LAUNCH. 

This case obtains if DRF=1 (dispatcher request flag), 
dispatching is not disabled, and no interrupt handler 
is pending. Note that it is possible for the dispatcher 
to preempt itself. 

Case 3: lEXIT should resume whatever code was running prior 
to the interrupt handler. This may be a lower priority 
interrupt handler that was pending or the dispatcher. 



The lEXIT description uses these uninterruptible sequences : 

RESTORE_REGS: begin P0P8B B5; .. POPBB BO; 

P0P4 X15; .. P0P4 XO; POPS SIATUSB; 
end 



RESTORE RETURN: 



RESTORE HP3000: 



begin S := Q + 120; RESTORE_REGS; 
EXIT; 
end 

begin 'P0P2' DelQ; Q := S - DelQ; 
'POPS' STATUSB; "P0P2' Z. OFFSET; 
'P0P2' DL. OFFSET; "P0P2' DB. OFFSET; 
'P0P2' DB.DST; 
end 
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lEXIT: if STATUSC.ICS = then Trap"INSPRIV"; 
if Q = QI and STATUSCl <> 7 then begin 
case_l: {return to task} 

STATUSC.ICS := 0; XM := TCB.XM; 
STATUSC.IE := 1; 
if XM = then begin 

{return to Vision mode} 
S := TCB.SNC0..63]; Q := S - 120; 
if TCB.SUIP = then RESTORE_RETURN 
else P := "SUITCHN" trap label; 
TCB.SUIP '.' 0; 
end 
else begin 

{return to HP3000 mode} 
S := TCB.SC[0..63]; 

RESTORE_HP3000; \ don't allow 

if TCB.SUIP = then 'EXIT 0' / interrupts 
else P := "SUITCHC" trap label; 
TCB.SUIP := 0; 
end 
end 
else if Q=QI or (STATUSC1=7 and (Q)[4]=l) then begin 
case_2: {stcirt dispatcher} 
Q := QI; DRF := 0; 
STATUSB := DispatcherStatusBInit; 
EXIT <<but leave S at Q>> {Q doesn't change} 
end 
else 
case_3: {resume code running before interrupted} 
RESTORE_REIURN; 



Note 1: implementations may substitute for the test Q = QI the 
test (Q-4)[0..31] = QI[32..63]. 

Note 2: "STATUSCl = 7" summarizes the condition that dispatching 
is both desired (DRF=1) and possible (DDC=0, etc). 



Status: restored from marker 
Traps: INSPRIV 

SIKUNF 

STKCONSISTV 

SUITCHN 

SUITCHC 

AddressingV on all base register loads 
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6.2.9.9 SUITCH 

Switch to HP3000 mode. See chapter 10.5.2.3, 

6.2.9.10 RSUITCH 

Reverse switch. See chapter 10.5.2.4. 

6.2.9.11 IDLE 

Idle loop. This instruction will cause no activity visible to 
software to occur until an external interrupt is 
raised. In a shared-memory multi-processor, no 
memory bandwidth should be consumed by this processor 
when in IDLE. This requires ring privilege. 

Traps: INSPRIV 

6.2.9.12 STOP 



07/31 



Stop. 



This instruction will cause the hardware to save all its 
cached values into their home locations in main memory, 
then release the memory bus and to wait for a hardware 
reset or some other condition not defined by this 
document. The intended use is for stop after power-fail. 
This instruction requires ring privilege. 



Traps: INSPRIV 
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6.2.9.13 SYNCOD loi.r4 

Synchronize changes to an OD. This instruction serves to warn 
hardware that the Object Descriptor corresponding to 
the logical object "loi" in the address space of the 
currently executing task on the processor executing the 
SYNCOD instruction has been changed. Hardware behavior 
of all processors in a shared-memory multi-processor 
system will reflect the new value of the OD no earlier 
than when the OD is changed in memory and no later than 
at the completion of the SYNCOD instruction, at the 
discretion of the hardware implementation. 
However, if the logical object whose OD is being affected 
matches the logical object id of any of the logical 
addresses in the following list, the effect of SYNCOD is 
undefined: 

P; Q,S; B0,...,B5; TCB.LA; QI; 

these reflect operating system errors. Similarly, if 
the OD change modifies the address or length of the TCB 
or ICS(QI) of a task currently executing on another 
processor in the sane shared-memory multi-processor 
system, the effect of SYNCOD is undefined. 
SYNCOD requires all other processors in a shared-memory 
multi-processor system to re-load their current values 
of P,Q,S,B0..B5 and for them to transfer control to a 
trap handler if their values are now invalid. 
SYNCOD requires ring privilege. 

Traps: INSPRIV 

Address ingV 
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6.2.9.14 SYNCTCB tcb.rS 

Synchronize task control block. This instruction warns hardware 
that some Group Descriptors in the Task Control Block 
at logical address "tcb" have changed. The behavior of 
address translation hardware will reflect the changes 
in the Group Descriptors no earlier than when the 
changes occur in memory and no later than when SYNCTCB 
is executed with the proper value of "tcb", the exact 
time being implementation dependent. 



Traps: INSPRIV 

Address ingV 



6.2.9.15 SYNCIB operand. nc, length. r4 

Synchronize instruction buffer. This instruction must be used 
to synchronize hardware whenever code is modified or 
when code cones into or goes out of existence through 
ODT modification. "Operand" identifies the first byte 
affected; "length" (in bytes; if negative, zero is used) 
indicates how many consecutive bytes are affected. 
Ring privilege and code access to "operand" is 
required. 



Traps: INSPRIV 
CODEODTV 
CODEBNDSV 
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6.2.9.16 TESTSEMA sena.mrw4, result. w4 

Semaphore test. This instruction is used for synchronization 

with other processors in a shared-memory multi-processor 
system. It is essentially a "test and set". The old 
value of "sema" is copied into "result". Then bit 
of "sema" is set to 1. Reading the most significant 
byte of "sema" and storing back the modified value is 
all done in a single uninterruptible operation. No 
memory access on behalf of any processor is allowed to 
intervene between the read of "sema" and the write of 
the modified value of "sema". 

The other three bytes of "sema" can be fetched either 
simultaneously to fetching the first byte or later 
(jointly, or individually) but not before. Condition 
code CCE is set when bit of "sema" was found clear, 
CCG is set when bit was found set. 
Note: for any restartable trap detected after the 
first byte has been modified, hardware must restore 
the first byte to its original value before passing 
control to the trap handler. 



Byte[0..7] := sema[0..7]; 

semafo] := 1; 

if Byte[0] =1 

then CC := CCG 

else CC := CCE; 

result [0.. 7] := Byte; 

result[8..31] := sema[8..31]; 



\ uninterruptible by 
/ other processors. 



Status: CC 



6.2.9.17 MOVESEMA source. r4, sema,mw4 

Move semaphore. This instruction copies the value of "source" 
into "sema" in one indivisible memory operation. No 
other hardw5ire activity is allowed to cause any part 
of "sema" to change until MOVESEMA has completed. 



sema := source: 
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6.2.9.18 DOUN sema.mnij4 


6.2.9.20 UP 8ema.mrw4 


Down semaphore (P) , This instruction performs the fast path of 


UP semaphore (V). This instruction performs the fast path of 


the Doun_senaphore operation (also known as 'P') or 


the Up_semaphore operation (also known as 'V') and 


else traps out to the trap handler for the slow path. 


traps to software for the slow path. "Sema" is a 


"sema" contains a bit for locking out other processors 


32-bit quantity in memory that contains a 'hardware- 


in a shared-menory multi-processor system; it also 


semaphore' bit and a 31-bit signed integer count. 


contains a 31-bit signed integer count. The address 


UP increments the count. Uhen the count remains 


of the neKt instruction and the address of "sema" 


negative, the slow path is taken. The trap handler 


are passed to the SEMADOUN handler. 


presumably launches the first task on the queue of 




tasks waiting for this semaphore. 




Note: for any restar table trap detected after the 


Label: TESTSEMA sema, Temp; \ busy-wait for 


semaphore word "sema" has been modified, hardware 


BRBUSY Label; / hardware semaphore 


must restore its original value before passing 


Count := Temp[1..31]; {sign-extended} 


control to the trap handler. The semaphore word 


if Count = -2**30 then Trap"SEMAOVF" 


is NOT restored when taking the "SEMAUP" trap. 


else begin 




Count := Count - 1; 




MOVESEMA Count, sema 


Label: TESTSEMA sema, Temp; \ busy-wait for 


if Count < then Trap" SEMADOUN" 


BRBUSY Label* / hardware semaphore 
Count := Temptl..31] {sign-extended}; 


end; 




if Count = 2**30-l then Trap"SEMAOVF" 




else begin 


Status; CC NOT affected 


Count := Count +1; 


Traps: SEMAOVF 


if Count <= then begin 


SEMADOUN 


Count[0] := 1; {NOT superfluous!} 




MOVESEMA Count, sema; 




Trap" SEMAUP" 




end 


6.2.9.19 TESTDOUN sema.mnii4 


else MOVESEMA Count, sema 




end; 


Test and Down semaphore. This instruction attempts a DOUN, but 




rather than trap out to software for the slow path, ^ it 




sets a condition code to reflect this fact and continues. 


Status: CC NOT affected 




Traps: SEMAOVF 




SEMAUP 


Label: TESTSEMA sema. Temp; \ busy-wait for 




BRBUSY Label; / hardware semaphore 




Count := Temp[l.,31]; {sign-extended} 




if Count = -2**30 then Trap"SEMAOVF" 




else begin 




TEST4 Count; 




if Count > then Count := Count - 1; 




Count [0] := 0; 




MOVESEMA Count, sema; 




end; 




Status: CC 




Traps: SEMAOVF 
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6.2.10 Arithmetic Conversion 



6.2.10.1 ISC42 source. r4, destination.w2 

Integer size check. The 16 least significant bits of "source" 

are moved to "destination". If the 17 most significant 
bits are not all the same, overflow is raised. 

destination[0. .15] := source [16. .31]; 
if source > 2'^15-1 or source < -2'^15 
then raise integer overflow; 

Traps: Ovflow 



6.2.10.2 CONVERT subopcode.rl, source. r, destination. w 

Convert types. "CONVERT" uses a subopcode to determine from what 
type to what type conversion is desired. The subopcode 
also controls rounding behavior when any floating point 
arithmetic is involved. 



subopcode 



|Rnd|Src-T|Dst_T| 



"Source" is interpreted to be of type "Src_T" and converted 
to the "Dst_T" type and stored in "destination". 

Rnd meaning 

round towards nearest unit, (if tie, round to even) 

1 round towards negative infinity 

2 round towards zero 

3 round according to STATUSB.FPC.RM 

Srcjr, Dst_T meaning 

32-bit integer 

1 64-bit integer 

2 32-bit IEEE floating point 

3 64-bit IEEE floating point 

4 128-bit IEEE floating point 
Conversion to and from decimal data is covered in 6.3. 



Status: Ovfl 
Unfl 

Traps: Arith 
FlArith 
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6.3 Decimal Instructions 



6.3.1 Packed Decimal Nimbers 



The packed decimal number format used in many of the instructions 
in the cobol emd decimal group is described here. External 
numeric format is described later in this introduction. In packed 
decimal format, a decimal digit is encoded in a nibble, using bit 
patterns 0000-1001 to encode 0-9. Two decimal digits are packed 
to a byte; the least significant decimal digit is packed in a byte 
together with a nibble encoding the sign. Packed decimal numbers 
may contain 0-31 digits. This amounts to 1-32 nibbles (counting 
the sign nibble), or 1-16 bytes. Packed decimal numbers always 
occupy an integral number of bytes, even if the number of decimal 
digits is even and therefore the number of nibbles is odd. A 
packed decimal number with an even number of digits must have a 
0000-nibble as its most significant nibble such as to fill out the 
byte. The address of the packed decimal number is the address of 
the byte containing the most significant digit. The standard sign 
nibble has the value 1100 for positive and 1101 for negative. Any 
other value for the sign nibble may produce unexpected results in 
packed decimal arithmetic. However, VALD (validate decimal) 
accepts sign nibbles 0000-1011, 1110 3ind 1111 as alternatives for 
positive and will change them to 1100. By software convention, 
1111 may be regarded as "unsigned". Decimal arithmetic on packed 
decimal numbers will always produce results with a standard sign 
nibble. Negative zero (i.e. a packed decimal number with a 
negative sign nibble) is not produced by packed decimal arithmetic. 
Using negative zero in pswiked decimal 6u*ithmetic may produce 
unexpected results. However, VALD accepts negative zero and will 
change it to positive zero. 
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The following comments apply equally to all packed decimal 
instructions described in sections 6.3.3,1 through 6.3.3.12. 

a) It is the responsibility of software to ensure that the 
"fill-out" nibble in a packed decimal with an even number of 
digits does indeed have the value zero. Hardware may treat 
this nibble as a normal significant decimal digit in a source 
operand. It is the responsibility of the hardware never to 
introduce a non-zero value in the "fill-out" nibble as a 
consequence of decimal arithmetic. It is the responsibility 
of hardware to set the overflow bit (or take the overflow 
trap) based on whether the resulting packed decimal number 
fits in the number of decimal digits specified in the 
instruction. Hardware must never overflow into the "fill- 
out" nibble. 

b) Uhen decimal overflow occurs with the overflow trap enabled, 
the source operands will be left unchanged by the instruction. 
A destination operand may receive a value that differs across 
hardware implementations (unless it coincides with a source 
operand) . 

c) It is the responsibility of software to ensure that there is 
no partial overlap between source operands and destination 
operands in the same instruction. It is the responsibility 
of hardware to ensure that total identity between source and 
destination operand is handled "correctly" (defined as 
producing the same result as would be obtained by completely 
pre-reading the source operand into a processor -private 
temporary area) . 

d) The length of a packed decimal operand is expressed by giving 
the number of decimal digits; in other words, the sign nibble 
is not counted, nor the "fill-out" nibble. Some packed 
decimal instructions include an explicit operand specifying 
the length of the packed decimal value; in others the length 
is implied by the opcode: for these, the length is either 7, 
15 or 31 digits, which corresponds to 4, 8 and 16 bytes. 

On loading decimal values in registers, they are always left- 
filled with zeros to reach 7, 15 or 31 digits. 
Explicit length operands must be checked by hardware to 
ensure they are between and 31. The "DECINVL" trap is 
taken for invalid length operands. 
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6.3.2 External Decimal Numbers 



The external numeric format uses a decimal representation of a 
number with one digit per byte, each digit is encoded in ASCII 
(48-57 corresponds to '0' - '9'). The sign is encoded by an 
"overpunch" in the least significant digit. An external numeric 
number consists of zero or more leading ASCII blanks followed 
by zero or more ASCII digits followed by an overpunched ASCII 
digit. Overpunched digits follows the conventions in the table 
below: 



digit 
value 



( 



positive 


negative 


overpunch 


overpunch 


'{' 


'}' 


'A' 


'J' 


'B' 


'K' 


'C 


'L' 


'D' 


'M' 


'E' 


'N' 


'F' 


'0' 


'G' 


'P' 


'H' 


'Q' 


'I' 


'R' 



unsigned 



The CVAD ir^truction recognizes a number in this external format 
and converts it to a number in packed decimal representation. 
The CVDA instruction converts a number in packed decimal format 
to external numeric format as described here. 
VISION does not directly support some decimal formats known as 
external numeric with leading overpunched sign, external numeric 
with trailing separate sign, external numeric with leading 
separate sign and unsignedexternal numeric. However, three 
special instructions TESTSTRIP, GETSIOI and OVPUNCH allow these 
other external numeric formats tobe converted to external 
numeric with trailing overpunched sign. 

TESTSTIP will strip the overpunched sign while recording the 
original sign information in the condition code. GETSIGN will 
extract the sign information from em overpunched sign digit and 
format it as an ASCII sign digit. OVPUNCH combines an unsigned 
digit and an ASCII sign digit and will produce from them the 
the corresponding sign-overpunched ASCII character. 
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6.3.3 Decimal Instruction Set 



6.3,3.1 ADDtD term.r, sum.rw 

Add decimal. "Term" is added to "sum" and the result is stored 
in "sum". The operands must be in the standard packed 
decimal format (such as produced by VALD) , otherwise 
results may differ across implementations. A decimal 
overflow occurs if all of the digits of the result do 
not fit in "sum"; if overflow is disabled, the left- 
truncated result is stored in "sum", else "sum" is 
left unchanged. 



ADD4D ADD8D ADD16D 

Status: Ovfl Ovfl Ovfl 

Traps: Opnd Opnd Opnd 

DECOVF DECOVF DECOVF 



6.3.3.2 SUBtD term.r, difference. rw 

Subtract decimal. "Term" is subtracted from "difference" emd 
the result is stored in "difference". The operands 
must be in the standard packed decimal format (such as 
produced by VALD) , otherwise results may differ across 
implementations. A decimal overflow occurs if all of 
the digits of the result do not fit in "difference"; 
if overflow is disabled, the left- truncated result is 
stored in "difference", else "difference" is left 
unchanged. 



SUB4D SUB8D SUB16D 

Status: Ovfl Ovfl Ovfl 

Traps: Opnd Opnd Opnd 

DECOVF DECOVF DECOVF 
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6.3.3.3 MPYtD factor. r, product. ru 

Multiply decimal. "Factor" is multiplied by "product" and the 
result is stored in "product". The operands must be 
the standard packed decimal format (such as produced 
by VALD), otherwise the results may differ eicross 
implementations. A decimal overflow occurs if all of 
the digits of the result do not fit in "product"; if 
overflow is disabled, the left- truncated product is 
stored in "product", else "product" is left unchanged. 



MPY4D MPY8D MPY16D 

Status: Ovfl Ovfl Ovfl 

Traps: Opnd Opnd Opnd 

DECOVF DECOVF DECOVF 



6.3.3.4 DIVtD divisor, r, quotient. rw 

Divide decimal. "Quotient" is divided by "divisor" and the 
result is stored in "quotient". The operands must 
be in the standard packed decimal format (such as 
produced by VALD) , otherwise the results may differ 
across implementations. DIVD truncates, i.e. it 
rounds towards zero. Decimal overflow occurs if all 
of the digits of the result do not fit in "quotient"; 
if overflow is disabled, the left- truncated result is 
stored in "quotient", else "quotient" is left unchanged. 
If "divisor" is zero, the result is indeterminate. 



DIV4D 
Status: Ovfl 
Traps: Opnd 

DECDVDZ 



DIV8D DIV16D 

Ovfl Ovfl 

Opnd Opnd 

DECDVDZ DECDVDZ 
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6.3.3.5 CMPtO sourcea.r, sourceb.r 

Compare decimal. The condition code in the status word is set 
depending on the result of the comparison of the 
decimal values of "sourcea" and "sourceb". Both 
operands must be in the standard packed decimal format 
(such as produced by VALD) , otherwise results may differ 
across implementations. 
The condition code is set to: 

CCG, if sourcea > sourceb, 
CCL, if sourcea < sourceb, 
CCE, if sourcea = sourceb. 



CMP4D CMP8D CMP16D 
Status: CC CC CC 
Traps: Opnd Opnd Opnd 



6.3.3.6 TESTtD source. r 

Test decimal. This is a short form of CMPtD source, 0. 



TEST4D 


TEST8D 


TEST16D 


Status: CC 


CC 


CC 


Traps: Opnd 


Opnd 


Opnd 
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6.3.3.7 SLD count. rl, length. rl, source. r, dest.w 

Shift left decimal. The packed decimal value in "source" is 
shifted left by "count" decimal places and the result 
is stored in "dest". Both "source" and "dest" have 
"length" digits. This is equivalent to a MOVED from 
"source" to "dest" followed by a MPYD of "dest" by a 
power of ten. 

Status: Ovfl 



6.3.3.8 SRD count. rl, length.rl, source. r, dest.w 

Shift right decimal. The peicked decimal value in "source" is 
shifted right by "count" decimal places and the result 
is stored in "dest". Both "source" emd "dest" have 
"length" digits. This is equivalent to a MOVED from 
"source" to "dest" followed by a DIVD of "dest" by a 
power of ten. 

Status: Ovfl 



6.3.3.9 MOVED length.rl, source. r, dest.w 

Move decimal. The packed decimal "source" with "length" decimal 
digits is moved to "destination" of the same length. 
If "source" is in a register, only the least significant 
"length" digits are moved, with overflow indication if 
any of the most significant digits in the register 
(register pair, quad) are non-zero. 

If "dest" is in a register, the decimal number is padded 
with zero digits to fill up either 1,2 or 4 registers. 



6-80 



VISION ARCHITECTURE CONTROL DOCUMENT 07/31 

DO NOT COPY — HP PRIVATE INFORMATION 



6.3,3.10 VALD length. rl, operand.™ 

Validate decimal. The packed decimal string "operand" is 
checked for validity as a decimal number. If 
"length" is even, the "fill-out" nibble is made 
zero. Each digit is checked to be in the range 
0000-1001. The sign nibble is made standard by 
replacing 0000-1001 , 1110 or 1111 with the value 
1100. If all digits are zero, but the sign is 
negative, the sign is changed to positive. 
"Length" indicates the length in digits of the 
packed decimal number. 



Traps: DECINVL 
DECINVDG 



6,3.3,11 CVDI length. rl, source, r, dest,u8 

Convert packed decimal to integer. The packed decimal number in 
"source", with "length" decimal digits, is converted 
to a two's complement 64-bit integer. The result is 
stored in "dest". "Source" must be in standard packed 
decimal format (such as produced by VALD) , otherwise 
results may differ across implementations. 

Traps: Ovfl 



6.3.3.12 CVID length. rl, source. r8, dest.w 

Convert integer to packed decimal. The 64-bit two's complement 
integer value in "source" is converted to a number in 
packed decimal format and padded or truncated to fit 
"length" decimal digits. The result is stored in 
"dest". If "dest" is in a register, the result is 
further padded to occupy 4,8, or 16 bytes. 

Traps: Ovfl 
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6.3.3.13 TESTSTRIP operand. rwl 

Test and strip sign from overpunched ASCII digit. The ASCII 

digit "operand" is changed to an unsigned digit aujcording 
to the table below. The condition code is set to CCG if 
the digit is found in the positive column, to CCL if the 
digit is found in the negative column and to CCE if it 
is found in the unsigned column. If "operand" is not in 
the table, an invalid digit trap occurs. 



positive negative unsigned 



^0' 
^1' 
^2' 
^3' 
"4' 
'5' 
'6' 
^7' 
^8' 
^9' 



all become: 



*0' 
'1' 
^2' 
^3' 
M' 
^5' 
:6' 
'7' 
^8' 
'9' 
^0' 



Status: CC 



6.3.3.14 GETSI(»I operand. rl, sign.wl 

Get sign. The sign- overpunched ASCII digit "operand" is examined 
and its sign (according to the table above) is recorded 
in "sign", using ASCII "+' for positive, "-' for negative 
and " ' for unsigned. Invalid values for "operand" will 
generate an invalid digit trap. 

Traps: DECINVDG 



6.3.3.15 OVPUNCH sign.rl, operand, rwl 

Create digit with overpunched sign, "Sign" must be ASCII "+', 
"-' or ' ' (blank). "Operand" must be one of the 
ASCII digits from '0' to "9'. "Operand" is changed 
into the corresponding element of the positive column 
or the negative column of the table above, depending 
on "sign". If "sign" is ' ', no change occurs. 
Invalid values for "sign" or "operand" generate an 
invalid digit trap. 



Traps: DECINVDG 
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6.3.3.16 VALN length. rl, operand. rw 

Validate external numeric decimal. This instruction checks to 
see if the external numeric decimal "operand" obeys 
the following format: zero or more ASCII blanks 
followed by zero or more ASCII encoded digits the last 
one of which is optionally overpunched with a sign 
according to the table on the previous page. "Length" 
indicates the length of "operand" in bytes. All leading 
blanks are converted into ASCII "0'. Negative zero is 
converted to positive zero. 

Traps: DECINVDG 



6.3.3.17 CVAD length. rl, source. r, dest.w 

Convert external numeric decimal to packed decimal. The "source" 
of "length" bytes is interpreted as an external numeric 
decimal number with trailing overpunched sign and 
converted to packed decimal format. The packed decimal 
result is padded to 4,8 or 16 bytes (no more than needed 
given "length") and stored in "dest". If source does 
not obey the format checked for and produced by VALN, 
indeterminate results occur. 



6.3.3.18 CVDA length. rl, source. r, dest.w 

Convert packed decimal to external numeric decimal. The "source" 
is interpreted as a packed decimal number. The "dest" 
is an external numeric decimal of "length" bytes. 
The length of "source" is 4,8 or 16 bytes, as derived 
from "length". If "source" does not obey the format 
checked for and produced by VALD, indeterminate results 
occur. 
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6.4 Vector Instruction Set 



This section describes the vector instruction set. Vector 
Registers and the vector context save area are described in 
chapter 5. 

Vector instructions are all in a secondary instruction set, in 
the "VECTOR" escape group. Opcode assignments are shown in 
section 6.1.4. 

A memory vector is an array of values that are evenly spaced in 
memory. An example would be a row or a column of a matrix in 
a Fortran program. Vector instructions can perform operations 
(such as addition) on entire memory vectors, at erpeeds higher 
than a corresponding software sequence. Vector instructions 
can also perform operations between memory vectors and scalars 
(e.g. multiplying all elements of a memory vector by two). 
Memory vectors are therefore characterized by their starting 
address, their number of elements, and the distance between 
consecutive elements. This distance between elements (in bytes) 
is called the stride of the vector. A memory vector with a 
stride of zero degenerates to a scalar. 

A major feature of the VISION architecture is the inclusion of 
vector registers . A vector register can be loaded with all or 
part of a memory vector, offering the potential of eliminating 
even memory access speed as a limit on vector performance. 

Most vector instructions operate on vector operands , which are 
either vector registers or memory vectors or scalar registers 
(X0..X15). Vector operands are indicated by the vector 
attribute(".v"). Under the vector attribute, an operand 
descriptor for a literal (short or long) is given a different 
meaning: the least significant 3 bits of the literal are 
interpreted as a vector register number, selecting VR0..VR7. 
Under the vector attribute, a memory operand is re- interpreted 
as a memory vector, as detailed below. A register operamd is 
interpreted as a scalar. 

To encode a memory vector, either one or two operand descriptors 
are needed. The second operand descriptor is needed when a 
memory vector has a stride different from the default value. 
The default stride is such that the memory vector is entirely 
contiguous in (virtual) memory. 

The first operand descriptor of a memory vector (treated as a 
".m" operamd) designates the starting address of the vector. 
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The vector opcode of a vector instruction does not uniquely 
determine how many operand descriptors participate in the 
instruction. A special first operand, called vector qualifier , 
contains the necessary information. This operand must be 
encoded as a short literal. Its value is interpreted as 
follows: 

2 3 4 5 6 7 

+ + — + — + — + + 

I res. |S1|S2|D | MR | 

+ + — + — + — + + 



07/31 



where: 
SI 



S2 



MR 



-- first source stride. If one, the first source operand 
uses an explicit stride. This implies that two 
operand descriptors are involved in this source 
operand. 

— second source stride. If one, the second source 
operand uses an explicit stride. 

-- destination stride. If one, the destination operand 
uses an explicit stride. 

-- mask register. Selects one of four mask registers. 
Their function is detailed below. 



res — reserved. Hardware masks out this field. 



The vector qualifier determines which operands carry explicit 
strides. These strides are encoded as ".r4" operands that 
follow all other operands in the vector instruction. 

An explicit stride is only meaningful if the corresponding 
operand is indeed a memory operand, indicating a memory vector. 
A vector register specifier or a scalar cannot make use of an 
explicit stride; in this case the bit in the vector qualifier 
is ignored. 
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6.4.1 Boundeiry conditions 

a) Any overlap between source and destination will produce 
results that may differ across implementations. Total 
identity of source and destination operands is allowed. 
For example, software may expect 

VADD4 B5.0, B5.0, 85.0 

to result in all values of the array at B5 to get doubled. 
However, software should not expect 

M0VE4 1, B5.0 
M0VE4 1, B5.4 
VADD4 B5,0, B5.4, B5.8 

to compute the Fibonacci series. 



b) Any overlap within the destination vector itself due to 
small values of the stride will produce results that may 
differ across implementations. 



c) All vector operations are interruptible, 
more detail. 



Chapter 5 provides 



d) For vector operations that have corresponding operations on 
scalars in the base instruction set, the values returned on 
e.g. overflow are the same as in the base instruction set 
with overflow trap disabled. If the trap is enabled, the 
vector operation stops as soon as the condition occurs on 
an element, and identifying information is passed to the 
trap handler. 
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6.4.2 Vector Arithmetic Operations 


6.4.2.6 VNEGt vqual.rl, source. vr, neg.vu 


6.4.2.1 VMOVEt vqual.rl, source. vr, dest.vw 
Vector move. 


Vector Negate. Element-wise subtract of "source" from zero, 
storing the result in the vector "neg" . 

includes: VNEG4 VNEG8 VNEG4F VNEG8F VNEG16F 


includes: VM0VE2 VM0VE4 VM0VE8 VM0VE16 


6.4.2.7 VABSt vqual.rl, source. vr, abs.vw 


6.4.2.2 VADDt vqual.rl, terma.vr, termb.vr, sum.vw 


Vector Absolute. Element-wise absolute value (negate if 

negative), storing the result in the vector "abs". 


Vector add. Elements of "sum" are set to the sum of elements 
of "terma" and "termb". 


includes: VABS4 VABS8 VABS4F VABS8F VABS16F 


includes: VADD4 VADD8 VADD4F VADD8F VADD16F 


6.4.2.8 VREMt vqual.rl, divd.vr, divsr.vr, rem. vw 


6.4.2.3 VSUBt vqual.rl, terma.vr, termb.vr, diff .vnr 


Vector remainder. Element-wise remainder of division of "divd" 
by "divsr" is stored in "rem". 


Vector subtract. Element-wise difference of "terma" and 
"termb" is stored in "diff" vector. 


includes: VREM4 VREM8 


includes: VSUB4 VSUB8 VSUB4F VSUB8F VSUB16F 


6.4.2.9 VMDDt vqual.rl, divd.vr, divsr.vr, mod.vw 


6.4.2.4 VMPYt vqual.rl, facta.vr, factb.vr, prod.va 


Vector modulus. Element-wise modulus of division of "divd" by 
"divsr" is stored in "mod". 


Vector multiply. Element-wise product of "facta" and "factb" 
is stored in "prod" vector. 


includes: VM0D4 VM0D8 


includes: VMPy4 VMPY8 VMPY4F VMPY8F VMPY16F 


6.4.2.10 VLSLt vqual.rl, shiftcount.vr, target. vrw 


6.4.2.5 VDIVt vqual.rl, divd.vr, divsr.vr, quot.vw 

Vector divide. Element-wise division of "divd" by "divsr" 
with the result being stored in "quot". 


Vector logical shift left. Element-wise left shift of the 
vector "target", leaving the result in "target". 
Note that the shiftcount itself is a vector. 

includes: VLSL4 VLSL8 


includes: VDIV4 VDIV8 VDIV4F VDIV8F VDIV16F 
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6.4.2.11 VLSRt vqual.rl, shiftcount.vr, target, vrw 


6.4.4 Vector Compare and Vector /Scalar Hybrids 


Vector logical shift right. Element-wise right shift of the 




vector "target", leaving the result in "target". 




Note that the shiftcount itself is a vector. 


6.4.4,1 VCMPt vqual.rl, field. rl, srca.vr, srcb.vr, mrsel.rl 


includes: VLSR4 VLSR8 


Vector Compare. "Field" indicates the type of compare (>, >=, 




etc.) to be performed. The four lecist significant 




bits of "field" indicate G,L,E,U respectively. All 




elements of "srca" are compared with the corresponding 


6.4.2,12 VASLt vqual.rl, shiftcount.vr, target. vu 


elements of "srcb" and the corresponding bit of the 




mask register (selected by the mask register selector 


Vector arithmetic left shift. Element-wise arithmetic left 


"mrsel" is set to one if the comparison holds. 


shift of the vector "target", leaving the result in 




"target". "Shiftcount" is itself a vector. 


includes: VCMP4 VCMP8 VCMP4F VCMP8F VCMP16F 


6,4.2.13 VASRt vqual.rl, shiftcount.vr, target. vw 




Vector arithmetic right shift. Element-wise arithmetic right 




shift of the vector "target", leaving the result in 




"target", "Shiftcount" is itself a vector. 


6,4,4,2 VACCt vqual,rl, terms, vr, sum,rw 




Vector Accumulate, Adds all elements of "terns" to the old 




value of "sum". 


6.4,3 Vector Logical Operations 






includes: VACC4 VACC8 VACC4F VACC8F VACC16F 


6,4,3.1 VAND4 vqual.rl, facta. vr, factb.vr, and.vw 






6,4.4,3 VACCDt vqual.rl, terns, vr, sum,rw 


Vector "AND". Computes element-wise and bit-wise "AND" of the 




vectors "facta" and "factb" and stores the result in 


Vector Accumulate (Double Precision). Adds all elements of 


the vector "and". 


"terms" to the old value of "sum". "Sum" has double 




the number of bytes of "terms". 




includes: VACCD4F VACCD8F 


6.4,3.2 V0R4 vqual.rl, terma,vr, termb.vr, or,vw 




Vector "OR", Computes element-wise and bit-wise "OR" of the 




vectors "terma" and "termb" and stores the result in 




the vector "or". 




6,4.3.3 VX0R4 vqual.rl, terma. vr, termb.vr, xor.vw 




Vector "XOR". Computes element-wise and bit-wise exclusive 




"OR" of the vectors "terma" and "termb" and stores 




the result in the vector "xor". 
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6.4.4.4 VMAXELt vqual.rl, terms. vr, naxind.ui4 

Find raaximuni element of vector. "Maxind" is set to the index 
of the maximum element of the vector "terms". In 
case of ties, the index of the earliest is chosen. 

includes: VMAXEL4 VMAXEL8 VMAXEL4F VMAXEL8F VMAXEL16F 



6.4.4.5 VMINELt vqual.rl, terms. vr, minind.w4 

Find minimum element of vector. "Minind" is set to the index 
of the minimum element of the vector "terms". In 
case of ties, the index of the earliest is chosen. 

includes: VMINEL4 VMINEL8 VMINEL4F VMINEL8F VMINEL16F 



6.4.4.6 VEXTt vqual.rl, terms. vr, index. r, value.© 

Extract element from vector. The element of "terms" at index 
"index" is fetched and stored into the scalar "value" 

includes: VEXT4 VEXT8 VEXT16 



6.4.4.7 VINSt vqual.rl, terms. vu, index. r, neuval.r 

Insert element into vector. The element of "terms" at index 
"index" is modified to reflect the value "newval". 

includes; VINS4 VINS8 VINS16 
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6.4.4.8 VCOMPRSt vqual.rl, terms. vr, compressed. vu 

Compress vector. The mask register indicated in "vqual" governs 
which elements of "terms" to keep and which to discard. 
The kept elements eure collected in "compressed". 
VCOMPRS will work correctly in place , i.e. when "terms" 
and "compressed" are memory vectors with identical 
starting address and identical stride. 

includes: VC0MPRS4 VC0MPRS8 VC0MPRS16 



6.4.4.9 VEXPNDt vqual.rl, terms. vr, expanded. vw 

Expand vector. The mask register indicated in "vqual" governs 
which elements of "expanded" are set to elements of 
"terms" and which to set to zero. The order of the 
elements of "terms" is preserved. If VEXPND is used 
in place , results are indeterminate. 

includes: VEXPND4 VEXPND8 VEXPND16 



6.4.4.10 VGATHt vqual.rl, source. vr, index. vr, destination. vw 

Vector Gather. Contiguous elements of "destination" are set to 
to those elements of "source" indexed by the contiguous 
elements of "index". The mask register indicated by 
"vqual" applies to "destination" and "index". "Index" 
is in units of bytes. 

includes: VGATH4 VGATH8 VGATH16 



6.4.4.11 VSCATt vqual.rl, source. vr, index. vr, destination. vw 

Vector Scatter. Contiguous elements of "source" are put in 
those elements of "destination" indexed by the 
contiguous elements of "index". The mask register 
indicated by "vqual" applies to "source" and "index". 
"Index" is in units of bytes. Those elements of 
"destination" not indexed are left unchanged. 

includes: VSCAT4 VSCAT8 VSCAT16 
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6.4.5 Vector Housekeeping 



6.4.5.1 RVLR 

Reduce Vector Length Register. The vector length register VLR 
is reduced by the current segment length. Condition 
codes are set to reflect the new value of VLR. 
See section 5.xx for details. 

Status: CC 



6.4.5.2 LDVLR source, r4 
Loaid vector length register. 

6.4.5.3 STVLR dest.w4 
Store vector length register. 

6.4.5.4 VINVAL vrmask.rl 

Vector invalidate. The Vector Registers corresponding to ones 
in the 8-bit "vmask" have their active lengths set 
to zero. 



6.4.5.5 UVCSA 

Update vector context save area. The values of the vector 

registers are stored in the Vector Context Save Area. 



6.4.5,6 PUVCSA tcb.mr 

Privileged update of VCSA. The values of the vector registers 
are stored in the Vecor Context Save Area of the 
designated task ("tcb" points to the Task Control Block 
of this task). PUCSVA requires ring privilege. 

Traps: INSPRIV 
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6,4.5,7 IVB tcb,i>ir 

Invalidate vector bank. Invalidates vector bank belonging to 
the designated task. Ring privilege required. 



6.4.5.8 LVB tcb.mr 

Load vector bank. Load the vector bsirik corresponding to the 
designated task from its VCSA. Ring privilege 
required. 



6,4.6 Operations on Mask Registers 



In the following instructions, "mrselect" is an operand that 
selects one of the four Vector Mask Registers. Only bits 
mrselect[6.,7] are relevant. Bits mrselect[0,,5] are ignored. 
Note that the Mask Registers are at most 256 bits long. 



6.4.6.1 CLRMR mrselect. rl 

Clear mask register. Set selected mask register to all zeros. 

6.4.6.2 STMR mrselect, rl, destination, iiil6 

Store mask register. Store selected mask register in 
"destination", 

6.4.6.3 LDMR mrselect. rl, source. rl6 

Load mask register. Load selected mask register from the value 
in "source". 

6.4.6.4 MRNOT mrselect. rl 

Complement mask register. Chsmge all zeros in the selected mask 
register to ones and vice versa. 
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6.4.6.5 MRAND mrasleect.rl, mrbselect.rl 

"AND" mask registers. Zero out all bits in mask register "mrb" 
that have zeros in the corresponding location in mask 
register "mra". 



6.4.6.6 MROR mraselect.rl, nrbselect.rl 

"OR" mask registers. Set all bits in mask register "nrb" to 
one that have ones in the corresponding location in 
mask register "mra". 



6.4.6.7 MRXOR mraselect.rl, nrbselect.rl 

"XOR" mask registers. Complement all bits in mask register 
"mrb" that have a one in the corresponding location 
in mask register "mra". 



6.4.7 Vector Conversion 



6.4.7.1 VCONVERT vqual.rl, typer.rl, source. vr, dest.vw 

Vector Conversion and Round. This instruction allows vector 
conversion from one type to another as specified in 
"typer". The vector "source" is converted and the 
result is stored in the vector "dest". 
Bits typer[2..4] determine the type of "source", 
bits typer[5..7] determine the type of "dest". 
Bits typer [0..1] are ignored. 
Data types are encoded in "typer" as follows: 

4-byte integer 

1 8-byte integer 

2 4-byte IEEE floating point 

3 8-byte IEEE floating point 

4 16-byte IEEE floating point 
5-7 illegal 

All conversions, including conversions from floating 
point numbers to integers, obey the rounding mode in 
STATUSB.FPC.RM. 
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6.5 I/O Instructions 



This sections details the instructions that deal with the I/O 
backplane and the I/O channels. 



6.5.1 PICMB-based VISION systems 



The PICMB instruction set can be broken down into two levels, 
primitives (level 1) and functions (level 2). These classes 
corresfpond to the PICMB protocol as defined in the PICMB ERS. 
The primitives represent the lowest level of activity on the 
PICMB; hence routines which make use of these must perform 
all bus protocols themselves. The function level instructions 
represent various functional combination of primitives. This 
level performs some of the PICMB protocol for the programmer, 
while retaining maximum flexibility. These two levels provide 
complete functionality for communicating with external devices. 
Each of these levels will be described in detail. The notation 
used in the following descriptions is intended to reflect the 
actual operation of the various data and control lines. 



6.5.1.1 PICMB Primitives 



6.5.1.1.1 IFC 

Interface Clesur. Causes hardware to assert the Interface Clear 
Line for one bus cycle. 

if STATUSA.XL > then Trap" INSPRIV"; 
IFC := true; 



6.5.1.1.2 UCMD command. rl 

Urite command. Send a command byte to the channel adapter. 

if STATUSA.XL > then Trap" INSPRIV" ; 
cobegin 

CDF := true; 

PICMB. CB. DATA := command [0. .7] ; 

coend; 



6-96 



VISION ARCHITECTURE CONTROL DOCUMENT 07/31 


VISION ARCHITECTURE CONTROL DOCUMENT 07/31 




DO NOT COPY ~ HP PRIVATE INFORMATION 


DO NOT COPY ~ HP PRIVATE INFORMATION 




6.5.1.1.3 UBYTE data.rl, end.rl 


6.5,1.2 Functional PICMB Instructions 




Urite byte. Causes hardware to write a byte to the chcinnel 






adapter. If "end" has a non-zero value, then the END 


The level 2 instructions correspond to the PICMB. CB commands as 




line will also be asserted. If the channel does not 


specified in the PICMB ERS. Some of these commands are global 




assert the SRT line within x milliseconds, the byte 


in nature and others are local. The global commands affect all 




will not be transfered and a timeout condition will be 


channels in a system and require no channel address. The local 




indicated by setting the condition code to CCL. 


commands are directed to a specific channel and require a channel 




A successful transfer will be indicated by CCE. 


jiddress operand. Uhen a local command is executed, all chemnels 
in the system which are not addressed will go into an idle state 
until a global command is issued or until they are locally 




if STATUSA.XL > then Trap"INSPRIV"; 


addressed. Global commands often return an 8-bit vector; the 




if not SRT then CC := CCL 


PICMB supports up to 8 channels. 




else begin 






CC := CCE; 






cobegin 






if end <> then END := true; 


6.5.1.2.1 CHNOP 




PICMB.CB.DATA := data 






coend 


Channel no operation. A NOP command is issued to all channels. 




end; 


if STATUSA.XL > then Trap" INSPRIV"; 




Status: CC 


UCMD 0; 




6,5.1.1.4 RBYTE data.wl 


6.5.1.2.2 RCL response. Ml 




Read byte. Causes hardware to read a byte from the channel 


Roll Call. This command is issued to all channels. 




adapter into "data". If the channel does not assert 






the SRT line within x milliseconds the data will not 






be read and a timeout condition will be indicated by 


if STATUSA.XL > then Trap" INSPRIV" ; 




setting the condition code to CCL. A successful 


UCMD "10; 




transfer will be indicated by CCE. A successful 






transfer when the END signal is asserted will be 






indicated by CCG. 


6.5.1.2.3 PRD response. wl 




if STATUSA.XL > then Trap" INSPRIV"; 


Poll Ready for Data. This command is issued to all channels. 




if not SRT then CC := CCL 






else begin 






data := PICMB.CB.DATA; 


if STATUSA.XL > then Trap" INSPRIV"; 




if END then CC : = CCG 


UCMD 120; 




else CC := CCE 


RBYTE response; <<no timeout>> 




end; 


Status: CC 




Status: CC 
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6.5.1.2.4 PDA response. wl 


6.5.1.2.7 UDP channel. rl, data.rl6, length.rwl 


Poll Data Available. This command is sent to all channels. 


Urite Data Packet. This command is sent to the specifically 




designated channel. The first "length" bytes of 


if STATUSA.XL > then Trap"INSPRIV"; 


"data" is sent to the channel. 


UCMD !30; 




KBYTE response; <<no timeout >> 






if STATUSA.XL > then Trap"INSPRIV"; 




Ch := channel AND 7; 


Status: CC 


PRD Temp [0.. 7]; 




if Temp[Ch] = then CC := CCL 




else begin 




Cmd := 160 + Ch; 


6.5.1.2.5 PAR response. ul 


UCMD Cmd; 
C := 0; 
repeat 


Poll Attention Requests. This command is sent to all channels. 




cobegin 




if C = length then END := true; 


if STATUSA.XL > then Trap"INSPRIV; 


UBYTE (data+C)[0..7]; 


UCMD !40; 


coend; 


RBYTE response; <<no timeout>> 


C := C + 1; 




until C>=length or 015 or CCL; 




if CCL then length := C; 


Status: CC 






Status: CC 


6.5.1.2.6 RDP channel. rl, dest,wl6, length. wl 




Read Data Packet. This command is sent to the designated 




channel and the data packet received is stored in 


6.5.1.2.8 RIS channel. rl, status. wl 


"dest". "length" will be set to the number of bytes 




in the data packet; if this is less than 16, the 


Read Immediate Status. This command is sent to the specifically 


remainder of "dest" will not be changed. 


designated channel. Its status is returned and stored 




in "status". 


if STATUSA.XL > then Trap"INSPRIV"; 




PDA Temp [0.. 7]; 


if STATUSA.XL > then Trap"INSPRIV"; 


Ch := channel AND 7; 


Ch := channel AND 7; 


if Temp[Ch] = then CC := CCL 


Cmd := !70 + Ch; 


else begin 


UCMD Cmd; 


Cmd := 150 + Ch; 


RBYTE status; 


UCMD Cmd; 




C := 0; 




repeat 


Status: CC 


RBYTE (dest+C)[0..7]; 




C := C + 1; 




until CCL or CCG or 015; 




length := C; 




end; ^ 




Status: CC 
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6.5.1.2.9 CIS Channel. rl, status. rl 


6.5.2 MPB-based systems 


Clear Immediate Status. This command is sent to the designated 




channel. The 8-bit status byte of the addressed 


The MPB is the memory-processor-bus defined and designed by 


channel is cleared in all bit positions corresponding 


SIO in Colorado. 


to a zero in "status". 






All I/O instructions for MPB based systems are "local": they 




address a specific chauinel by specifying the channel number. 


if STATUSA.XL > then Trap" INSPRIV"; 


The channel number is mapped at configuration time to a slot 


Ch := channel AND 7; 


number on the MPB backplane. This ranges from 0..7. 


Cmd := !80 + Ch; 


Though the MPB backplane and the I OP channel were designed 


UCMD Cmd; 


as a pair, the Vision I/O instructions for the MPB are 


UBYTE status; 


designed to allou channels other than the lOP to connect to 




the MPB. 


Status: CC 






6.5.2.1 MPB-based Instructions 


6.5.1.2.10 SIS channel. rl, status. rl 




Set Immediate Status. This command is sent to the designated 




channel. The 8-bit status byte of the addressed 


6.5.2.1.1 lOU channel. r4, control. r4, data.r4 


channel is set in all bit positions corresponding 




to a one in "status". 


I/O Urite. This writes the data word "data" to the channel 




designated by "channel". "Control" is a modifier 




interpreted by the channel. 


if STATUSA.XL > then Trap" INSPRIV"; 




Ch := channel AND 7; 


if ETTATUSA.XL > then Trap" INSPRIV" ; 


Cmd := !90 + Ch; 


Ch := channel AND 7; 


UCMD Cmd; 


Cntr := control; 


UBYTE status; 


Cntr[0..5] := 0; 




Cntr [19.. 21] ; = MPB_ch2innel_number_of_ 




originating CPU; 


Status: CC 


Urite Ch, Cntr, Data {to MPB}; 




6.5.2.1.2 lOR channel. r4, control. r4, data.u4 




I/O Read. This reads the data word "data" from the channel 




designated by "channel". "Control" is a modifier 




interpreted by the channel. 




if STATUSA.XL > then Trap" INSPRIV"; 




Ch := channel AND 7; 




Cntr := control; 




Cntr[0..5] := 0; 




Cntr [19.. 21] := MPB_channel number of_ 




originating CPU; 




Read Ch, Cntr, Data {from MPB}; 
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6.5.2.1.3 IOC channel. r4, control. r4 

I/O Control. This performs a control function on the channel 
designated by "channel". "Control" is a modifier 
interpreted by the channel. 



if STATUSA.XL > then Trap"INSPRIV"; 

Ch := channel AND 7; 

Cntr := control; 

Cntr[0..5] := 0; 

Cntr [ 1 9 . . 2 1 ] ; = MPB_channe l_number_o f _ 

or iginating_CPU ; 
Control Ch, Cntr {on MPB}; 



6.5.2.2 Interpretation of the control word on the lOP 



The control word detailed in the previous section has a 
well-defined meaning when used with the I OP channel. 
This is sketched below. More detail is available from 
the FOCUS I/O ERS. 



11 112222 3 
568923 891245 1 

I res. I PA I IC I res. |OCN|res| 10 OPC| 
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Control 
word 



Here: 



res. = reserved 

PA = either subchannel number or device adapter number. 
The 10 opcode "10 OPC" will decide which. 

IC = interface control. This four bit field allows for 
control of the HPIO lines shown below: 
ICl -> BP[0] HPIO bus primitive/interface control 
IC2 -> CEND HPIO channel end 
IC3 -> CBYT HPIO channel byte 
IC4 -> BP[1] HPIO bus primitive/interface control 

OCN = channel number of cpu originating the command 

10 OPC= 10 opcode. This 7-bit value is defined as shown 
in the following section. 
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6.5.2.3 lOP Opcodes 



6.5.2.3.1 Read commands 



Name 



Mnemonics Hexadecimal 



Read DMA Current Address 
Read DMA Current Count 

& Status 
Read DMA Mask 
Read Interrupt Mask 
Read Interrupt Request 
Interface Poll 
Read DMAPA 
Read Data Buffer 
Read I OP Revision 
Read Interface Status & Flag 
Read Interface Status 
Read Interface Flag 
Read DMA Termination Field 
Read I OP registers & Suspend 
Read Interface Device End 

& Burst Request 
Read Interface FRn 



RDA 


7 


RDCS 


8 


RDMK 


B 


RIMK 


16 


RIRQ 


IC 


I FPL 


27 


RDPA 


2D 


RDB 


2E 


RIRV 


2F 


RISF 


3F 


RIST 


43 


RIFG 


44 


RDTF 


45 


RIRS 


48 


RDEB 


4E 


RIF n 


(8*n + 1) 



6.5.2.3.2 Urite Commands 



Name 



Mnemonics Hexadecimal 



Urite DMA Status 

Urite DMA Count 

Urite DMA Start Address 

Urite DMA Termination Field 

Urite Interrupt Mask 

Urite Interrupt Message 

Set Interrupt Level 

Urite DMAPA 

Urite MPB Channel Number 

Urite Attention Poll Mask 

Urite lOP Registers & Resume 

Urite Interface FRn 



UDS 


3 


UDC 


4 


UDA 


5 


UDTF 


6 


UIMK 


15 


UIMG 


IB 


SIL 


ID 


UDPA 


2C 


UMCN 


30 


UAMK 


46 


UIRR 


4B 


UIF n 


(8*n 



2) 
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6.5.2.3.3 Control Commands 



Name 

Clear DMA Mask 

Enable DMA 

Disable DMA 

Start DMA, Enable Interrupt 

& Clear IRQ 
Start DMA & Clear IRQ 
Start DMA 

Start RAMD, Clear IRQ 
Request Interrupt 
Clear Interrupt Request 
Enable Interrupt 
Disable Interrupt 
Reset I/O Bus 
Reset TOP 

Clear Address Lockout Mode 
Set Address Lockout Mode 
Initiate Ciad Exec from 

Interrupt 
Disable I OP Command Execution 
Disable Command Execution & 

Enable Interrupt 
Turn LED On 
Turn LED Off 
Clear Attention Acknoul. Bit 



6,5.2.3.4 lOP Command Execution 



Mnemonics Hexadecimal 



========= 




CDMK 


C 


EDMA 


D 


DDMA 


E 


SDEC 


F 


SDC 


10 


SD 


13 


SRC 


14 


RINT 


17 


CIRQ 


18 


EINT 


IE 


DINT 


IF 


RIOB 


28 


RIOP 


2B 


CALM 


33 


SALM 


34 


ICEI 


38 


DCE 


3B 


DCEI 


3C 


LON 


3D 


LOFF 


3E 


CAAK 


47 



Name 


Mnemonics 


Hexadecimal 


Increment And Branch 




35 


Skip on Status False 




36 


Skip on Flag False 




37 


Urite RIF Result to Memory 


URIF 


4C 


Urite Count & Status to 






Memory 


UCSM 


4D 



6-105 



VISION ARCHITECTURE CONTROL DOCUMENT 
DO NOT COPY — HP PRIVATE INFORMATION 



07/31 



6.6 Diagnostics Interface 



6.6.1 MOVEtCSP 



messlen.r4, messpa.r4, replylen.r4, replypa.r4, 
error. wl 



Move message to CSP. Send to the CSP (Control and Support 

Processor) a message consisting of a string of bytes, 
"messlen" long, starting at physical address "messpa". 
An area in physical memory is reserved for a reply, if 
tlnere is one, of length "reply len" (in bytes), starting 
at physical auldress "replypa". Message and reply format 
may differ across VISION implementations. Refer to the 
"Protocol of the Control and Support Processor for VCF60 
and VCF50" document. Receipt of a reply from the CSP 
will generate an internal interrupt IICSPREPLY. Actual 
transmission of the message and the reply may occur at 
any time between execution of the MOVEtCSP instruction 
and the IICSPREPLY. During this interval, the message 
and reply areas in physical memory must not be accessed 
by software. This isntruction requires Ring privilege. 
"Error" can have the following values: 



= Instruction accepted, transmission beginning 

1 = This VISION implementation has no CSP 

2 = CSP busy, cannot accept a message 

3 = Requested operation not implemented by CSP 

4 = message or reply area wrong physical address 

or length 
5-255 = reserved values, will not be returned 



Note: "*" means that the instruction was not 

cu^cepted and no transmission was initiated. 



Traps: INSPRIV 
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INTERRUPTS AND TRAPS 



CHAPTER 7 



7.1 Introduction 



Interrupts and traps are examples of a broad set of conditions 
called "exceptions" that redirect the normal flow of machine 
instiructions. Generally, instructions are divided into a 
sequence of smaller actions referred to as "steps". Steps are 
defined for either of two reasons: 

1) The execution of an instruction step results in a change in 
the machine state (e.g., a byte of memory modified, a 
register modified) . In this case a step may not be 
repeatable. That is, if the machine state that resulted 
from a step were used as the input state to the same step, 
a different output machine state might result. 

2) The step represents a large amount of processing. In this 
case if the instruction were interrupted, too much 
processing would be lost. Even though the machine state 
hasn't been modified (as part of the instruction execution 
so far) it is still desirable to define an intermediate 
state for the instruction. 

Each instruction step is composed of one or more "sub-steps". 
A sub-step represents an uninterruptible sequence of operations. 
All steps are architecturally defined. The instruction 
descriptions define the intermediate state of all instructions 
that have multiple steps. No other steps or intermediate states 
are allowed. Instructions which execute very quickly (short in 
tine) have only a single step while other instructions, such as 
MOVEC (move character), are composed of many steps. The 
following diagram illustrates this concept of an instruction: 



|< an instruction >| I <-an instruction ->| 

v V V V 

Pcurrent Pnext 

+ + + + + + + + + + 

Sequence | I I I I II II I 

of I step 1| I step 2| ... jstep m| Istep 1| ... I step n| 

Steps I II II II II I 

+ + + + + — , — + + + + + 
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There are multiple conditions that caui occur during the execution 
of an instruction that cause the normal flow of control to be 
altered. In the previous illustration the normal flow of control 
is to execute the instruction located at Pcurrent and then to 
execute the instruction at Pnext. The diagram above shows the 
steps normally executed for these instructions in the absence of 
an exception. This diagram is independent of the existence of 
multiple execution paths that are data dependent. However, if an 
exception condition(s) is detected during the execution of 
Pcurrent, the next instruction to be executed by the CPU will be 
the handler for the condition. Some exception conditions (such as 
page fault) are specified to be transparent to the current 
instruction execution. For these conditions the current 
instruction is resumed after the exception handler completes so 
that the net effect of the exception is as though it did not occur 
at all. Other exception conditions (such as overflow) arise as a 
direct consequence of executing the current instructions. For 
these exceptions the specific exception defines whether Pcurrent 
or Pnext is the location to resume instruction execution. 

Exceptions are classified into three general categories: 

1) external interrupts 

2) internal interrupts 

3) traps 



7-2 



VISION ARCHITECTURE CONTROL DOCUMENT 
DO NOT COPY — HP PRIVATE INFORMATION 



07/31 



7.1.1 External Interrupts Overview 



External interrupts are generally service requests from I/O devices. 
External interrupts are polled for between the execution of 
instruction steps. The following diagram illustrates this: 



|<— - 

V 

Pcurrent 



an instruction 



Sequence I I 

of I step 11 

Steps I I 



I step 2 1 



I I 



I step ml 



|<-an instruction- > I 

V V 

Pnext 



I step 11 



I step n| 



Trap and 
Interrupt 
Poll 
Sequence 



where X = external interrupt poll 

Uhen multiple external interrupts are pending, one is selected 
(based on the interrupt mask and on priority) . The other 
external interrupts are left pending and are allowed to cause an 

external interrupt later (when no longer masked). 
External interrupts generally are unrelated to the current 
instruction being executed. The architecture requires that the 
effect of processing external interrupts be transparent to the 
current instruction. Therefore, the execution of the current 
instruction can be suspended between any two steps as long as 
execution resumes at the next step (technically, execution can 
resume at any previous step as long as the effects of the 
intermediate steps can be undone or rolled back). The normal 
processing sequence for external interrupts is to "cap off" the 
current stack with an interrupt marker (preserving the current 
machine context) and to transfer control to the exception handler 
executing on the interrupt control stack. 



7.1.2 Internal Interrupts Overview 



Internal interrupts normally originate from some type of abnormal 
condition occuring within the system not associated with the 
execution of the current instruction. Some examples of internal 
interrupts are powerfail, parity error and machine checks. 
Internal interrupts are polled between the execution of instruction 
steps. If an internal interrupt is detected, external interrupts 
are not polled. 
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The following diagram illustrates this sequence: 



|< an instruction >| |<-an instruction-) I 

I III 

V V V V 

Pcurrent Pnext 

+ + + + + + + + + + 

Sequence I | I I I | I | I | 

of Istep 1| Istep 2| .. Istep m| jstep 1| .. Istep n| 

Steps I II II II II I 

+ + + + + + + + + + 



Trap and 
Interrupt 
Poll 
Sequence 



II 
IX 



II 
IX 



II 

IX 



II 

IX 



where I = internal interrupt poll 
X = external interrupt poll 



Internal interrupts are handled by pushing a marker (either an 
interrupt marker or a procedure stack marker depending upon the 
exception) onto the current stack and then transferring control to 
the exception handler. The exceptions that push an interrupt 
stack marker execute on the interrupt control stack (ICS). Those 
exceptions that push a (procedure) stack marker execute on the 
current stack. 

Multiple internal interrupts are processed by pushing markers onto 
the stack in increasing priority, then continuing execution with 
the handler of the latest (highest priority) internal interrupt 
pushed (interrupts are processed in reverse order — last- in- 
first-out). Note, the occurrence of an internal interrupt is 
remembered by pushing a marker onto the stack so that the handler 
will execute. This technique contrasts with external interrupts 
which are remembered with status bits. The following diagram 
illustrates the stack state(s) following the detection of: 

1) an internal interrupt "A" that runs on the current staw;k, 
and 

2) two internal interrupts, "B" and "C", respectively, that 
execute on the ICS. 
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Using the current stack for processing traps allows the naxinun 




Interrupt 


degree of concurrency between tasks because the handlers themselves 


Current 


Control 


run in a general task environment. This is unlike the interrupt 


Stack 


Stack 


control stack which requires a strict adherence to last- in- first- 
out processing of events with no option to suspend execution while 


_ — _— ._ — _^_^. 


"* "~ "" 




1 dispatcher I 


using the ICS. 






QI—>| interrupt | 








1 stack marker I 
1 


The following diagram illustrates the relationship between the 
polling of internal and external interrupts £ind the detection of 




1 1 




SI— >| parameters | 

1 for 1 

1 handler "B" j 
1 1 


trap conditions. 

1 < an instruction 




IIIP save areal 




1 procedure | 


1 1 

1 interrupt | 


>| 1 < -an instruction- >| 


[stack marker j 


Qc — >| marker for j 


1 


II 1 


Ifor 1 


[returning to | 


V 


V V V 


1 interrupted I 
1 instruction 1 


[interrupt "B"| 


Pcurrent 
+ + + + + 


Pnext 

_+ + + + + 




1 parameters I 


Sequence I | I | | 


1 i 1 1 1 


1 parameters | 


1 for 1 


of istep 1| jstep 21 .. jstep 


ml Istep 1| .. Istep n| 


1 for 1 
1 handler "A" | 


1 handler "C" j 

1 1 


Steps 1 II II 


II III 


1 — — 1 
Sc~>| |<~ Control 

1 1 transferred 


+ + + + + 


•"+ +_ — — «. — + ^_____— ^ 


1 interrupt I 


Trap and 


AAAA AAAA 


1 marker for j 


to 


Interrupt 1 1 II 1 II 1 


INI MM 


1 returning to 1 


handler "C" 


Poll TRIX TRIX 


TRIX TRIX 


[handler "A" I 




Sequence 

where I = internal interrupt poll 




S-->| 1 








X = external interrupt poll 








T = trap condition detected 








R = trap condition reported 


(trap handler activated) 






\ = part of the step(s) not 


executed 


7.1.3 Traps Overview 












The specification of each individual trap condition determines the 


Traps include all exception conditions which arise as a direct 


next instruction step to be executed. 




consequence of instruction execution. Examples include traps for 






arithmetic overflow, ODT access rights violation, page fault and 






hreakpoint (dehug) . Generally, traps are detected by microcode 






during the execution of 


ax\ instruction step. For traps the normal 






processing sequence is 


to push an external procedure stack marker 






onto the current stack, 


push the parameters on the current stack 






and then execute the handler on the current stack. An external 






procedure stack marker 


is pushed for each different trap detected. 






Depending upon the type 


of trap (see the definition of restar table 






and continuable traps). 


the stack appears as though an explicit 






procedure call was made 


to the trap handler either just before the 






Pcurrent instruction or 


after the Pcurrent instruction. 
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The following diagram illustrates the stack state following the 
detection of two traps, X and Y, in the same step. 


1) Non- recoverable traps 






Current 
Stack 


A non- recoverable trap catches the occurrence of a machine state 
that makes it impossible for the hardware implementation to be 
able to guarantee correct completion of the instruction even if 
the trap handler fixes the immediate problem. An example is 
overflow of the dispatcher disable count or detection of 
inconsistent Q and S values on I EXIT. Uhenever a non- recoverable 
trap occurs, the simultaneous occurrence of other types of traps 
is irrelevant. 

2) Recoverable Traps 




1 . 1 




1 IIP save areal 




1 procedure | 

1 stack marker | <== Returns to interrupted 

1 for the 1 instruction 

1 interrupted j 

1 instruction | 




The other categories of traps are part of a set of recoverable 
exceptions. For these traps it is expected that software can "fix 
up" the cause of the trap and can re-execute the instruction or 
software can substitute a "reasonable" result for the instruction. 


Qx 


= > 1 parameters I 
[for handler x| 


Sx 


= > 1 procedure I 

1 stack marker | <== Returns to handler X 
ifor returning! 
ito handler X 1 


2a) Restartable Traps 




A restartable trap is a trap that occurred before the instruction 
was complete and requires that any changes to the machine state 
(as part of the current instruction) be undone or "backed out" by 
the CPU before transferring control to the trap handler. After 
the trap handler has executed and fixed the problem that caused 
the trap, the instruction is restarted from the first step. The 
following diagram illustrates this sequence. 


Qy 


=>| parameters I 
Ifor handler Y| 


Sy 


= >l 1 


Traps are divided into five categories: 

1) non- recoverable traps 

2) recoverable traps 

2a) res tar table traps 
2b) continuable traps 
2c) step-restartable traps 
2d) step-continuable traps 


|< — an instruction >| |<-an instruction- > I 

1 II 1 

V v V V 

Pcurrent Pnext 

+ + + + + + + + + + 

Sequence | j | | | | I | | | 

of Istep Ij Istep 21 .. Istep ml Istep 1| .. Istep n| 

Steps 1 II II II II 1 

'^+ + + + + + + + + + 

1 1 






1 + ^ 1 

1 1 recovery! I 
~| block |<~ 






Trap and """ 

Interrupt 1 1 1 j 

Poll RIX T 

Sequence 
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where I = internal interrupt poll 
X = external interrupt poll 
T = trap condition detected 

R = trap condition reported (trap handler activated) 
\ = part of the step(s) not executed 



On the previous diagram, a restartable trap could have been detected 
as part of step 1 through m. On detecting the trap condition, the 
machine would be restored to its value prior to executing step 1 of 
the instruction. The program counter value Pcurrent is saved in the 
stack marker. Then, Pcurrent mill be executed again when the trap 
handler EXITs back to the instruction sequence. At entry to the trap 
handler the stack state will be: 

Stack 



I procedure stack | 
I marker to | 
I instruction Pcurrent | 

+ + 

Q==> I parameters for trap | 
handler 



S==>| 
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2b) Continuable Traps 



A continuable trap is a trap that serves as an alternate exit point 
from the instruction. An example is integer overflow. Uhen overflow 
is detected, the remaining steps in the instruction are skipped. The 
result of the instruction is the overflow condition. For a continuable 
trap, the next instruction, after the trap handler, to be executed is 
Pnext. The following diagram illustrates this: 



l< 

1 

V 

Pcurrent 
+ + 

Sequence I I 

of istep 1| 

Steps 1 1 

+ + 


an 


instruction 

+ + 

1 W\l 
Istep 21 .. 

1 W\l 

+ + 

1 


>| |<-an instruction- > 

1 1 

V V 

Pnext 
+ + + + + 

IWWWI 1 1 1 
Istep mi Istep 1| .. jstep 2 
IWWWI ^ 1 1 1 

1 


Trap and 
Interrupt 
Poll 
Sequence 


1 

T 


III 

RIX 



where I = internal interrupt poll 

X = external interrupt poll 

T = trap condition detected 

R = trap condition reported (trap hamdler activated) 

\ = part of the step(s) not executed 

In the case of a continuable trap, the software trap handler has the 
option of altering the result of the instruction by modifying (again 
from software) the result operand. Then execution can be continued 
from Pnext. This case is very similar to the ordinary external proce- 
dure call. The hardware is not required to be able to undo any state 
changes it has already comroitted. 
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At entry to the trap handler, the stack state will be: 
Stack 



07/31 



I procedure stack 

I marker to 

I instruction Pnext 



Q==> I parameters for the 
I trap handler 



2c and 2d) Step-Restartable and Step-Continuable Traps 



The step-r ©star table and step-continuable traps are very similar to 
the restartable and continuable traps respectively, but they arise 
in the context of certain instructions, such as MOVEC, that consist 
of certain steps repeated a number of times. These instructions have 
an architecturally defined interrupt state from which they can resume 
execution safely. A bit in the machine register STATUSA (IIP — 
"instruction in progress") allows a decision at instruction fetch time 
as to whether the instruction has already executed certain steps. If 
so, the parameters to restart the instruction's execution are popped 
from the stack and then the instruction is completed. This same 
mechanism which allows external interrupts to occur in the middle of 
an instruction also allows internal interrupts and recoverable traps 
to occur in the middle of the execution of a step without having to 
back out of more than the last (current) step. 

The following diagram illustrates the step-restartable and 
step-continuable concepts: 
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Step- Resteur table: 



V 

Pcurrent 



Sequence I | 

of I step 1| 

Steps I I 



£in instruction >| |<an ins true t ion > I 

I I I 

V V V 

Pnext 

+ + + + + + + + 

I II II II I 

Istep 2|..|step ml Istep l|..|step n| 

I II II II I 

+ + + + + + + + 



I recovery I I 
I block |<- 



Trap and 
Interrupt 
Poll 
Sequence 



III 
RIX 



Where I = internal interrupt poll 
X = external interrupt poll 
T = trap condition detected 

R = trap condition reported (trap handler activated) 
\ = part of the step(s) not executed 

At entry to the trap handler, the stack state will be (except for the 
top of stack page fault which is handled like an internal interrupt): 



Stack 



III? information I 

+ + 

I procedure stack I 
[marker to resume I 
I instruction Pcurrent j 

+ + 

Q==> I parameters for the | 
I trap handler I 

+ + 

S==>| I 
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Step-Continuable: 



an instruction 



<-an instruction- > 



V V V V 

Pcurrent Pnext 

+ + + + + + + + + + 

Sequence I \\| I II II II I 

of I step 11 I step 2 1 .. I step ml I step 1| .. I step n| 

Steps I \\|^ I II II II I 

+ +" + + + + + + + + 

I I 



Trap and 
Interrupt I 
Poll T 
Sequence 



RIX 



where I = internal interrupt poll 
X = external interrupt poll 
T = trap condition detected 

R = trap condition reported (trap handler activated) 
\ = part of the step(s) not executed 



At entry to the trap handler, the stack state will be: 



Stack 



I IIP information I 

+ + 

I procedure stack I 
I marker to resume I 
I instruction Pcurrent I 

+ + 

Q= = > I parameters for the I 
I trap handler I 



S= = >| 
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Debug Traps: 



The debug traps are a special case of traps. If during the eKecution 
of an instruction, microcode detects that the instruction is modifying 
a location covered by a data breakrange then the DBP (debug breakpoint 
pending) flag in STATUSA is set to remember that the breakpoint was 
encountered. Then, the instruction execution is continued with the 
setting of the breakpoint flag being somewhat transparent. Then, at 
the end of the instruction execution, the breakpoint handler is 
activated. By handling the trap at the end of the instruction, the 
architecture guarantees to report a breakpoint to software only once 
per instruction. The following diagram illustrates this sequence: 



an instruction 



I <-an instruction- > I 



Pcurrent 



Pnext 



Sequence I | | I | | | | | | 

of Istep 1| Istep 2| .. Istep ml Istep 1| .. Istep n| 

Steps I II II II II I 



Trap and 
Interrupt 
Poll 
Sequence 



II 
IX 



ill 
RIX 



where I = internal interrupt poll 
X = external interrupt poll 
T = trap condition detected 

R = trap condition reported (trap handler activated) 
\ = part of the step(s) not executed 
At entry to the debug traps, the stack state will be: 

Stack 



I procedure stack 
(marker to return to 
I instruction Pnext 



Q==> I parameters for the 
I trap handler 

S">| 
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7.1.3.1 Special Programming Notes 
STATUSB Handling 



Uhen control is transferred to enception handlers that execute 
on the current stack, an external procedure call marker is pushed 
onto the stack. This marker includes the STATUSA register, but 
not the STATUSB register. In order not to have any side effects 
on the suspended instruction, software must save STATUSB at entry 
to the handler. Then, immediately prior to EXITing back to the 
suspended instruction, the handler should restore STATUSB to its 
value when the trap was detected. 



Hardware versus Software Recoverability 



The classification of the recoverability of a trap condition is 
based upon whether or not software can remove the condition that 
caused the trap and can then allow the hardware to proceed with 
instruction execution. Instruction execution can proceed from 
either the instruction that caused the trap or the instruction 
following. This criterion for classification is more permissive 
than one based strictly on whether machine state has been 
modified. As an example, if a M0VE8 from location A to location B 
were to get a bounds violation on B, part of B might have been 
modified before the bounds violation was detected. If the trap 
handler increases the upper bound of the object containing B such 
that the MOVES no longer causes a bounds violation, the net effect 
is that the trap did not occur. This example illustrates a case 
where the hardware could not restore the contents of location B 
but software could fix the problem. So from a hardware perspective 
the input state of the instruction cannot be recreated. From a 
software perspective the instruction is restartable. Using the 
classification criterion, this bounds violation is recoverable. 
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7.2 Detail Description of External Interrupts 



7.2.1 Processor context for interrupts 



Three items of processor context define the interewjtion between 
processor and interrupts. There is an Interrupt Enable/Dissible 
bit in STATUSC, called STATUSC.IE or "IE" for short. This bit 
controls whether any interrupts are allowed to cause a change in 
the sequence of execution of macro- instructions. There is a 16- 
bit Interrupt Mask Register in STATUSC, called STATUSC. IMR or 
"IMR" for short. This mask controls which interrupts are allowed 
to cause a change in the sequence of execution and which are not, 
subject to STATUSC.IE. Finally, there is an Interrupt Pending 
Register, which is not directly accessible to software; hence 
implementations have a large amount of freedom in how to implement 
it. It need not even exist as a separate entity in the machine, 
as long as the behavior that is here ascribed to it can be 
reproduced. The Interrupt Pending Register looks like an array 
as in Pascal: 

TYPE 

pr_level: 0..15; 

source: (i_channel, ijrocessor) ; 

state: (clear, set); 
VAR 

IPR: ARRAY [pr_level, source] OF state; 

The IPR is processor- local. Details on multiprocessor aspects of the 
interrupt system follow in section 7.2.7. 



7.2.2 General operation 

Interrupts cause bits to get set in IPR (elements of IPR to 
become 1). The state of the Interrupt Mask Register and the 
state of the Interrupt Enable/Disable bit control whether the 
processor is notified or wether the interrupt is held off. 
Interrupts can be caused by chainnels or by a processor itself 
under software control. 
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7.2.3 Channel Interrupts 



Each hardware channel is configured at a specific priority 

pr : pr_level; 

If the channel wants to raise an interrupt, it does so by setting 
the appropriate bit in I PR: 

IPR[ pr, i_channel ] :=set; 

If STATUSC.IE = 1 and IMR[pr] = 1, the processor is interrupted at 
the first convenient opportunity (e.g. between instructions), 
otherwise the interrupt is held off. The channel must be prepared 
to inform the processor of details concerning the interrupt when 
the interrupt is acknowledged. To this end, the channel may use 
an area of the processor's memory (called "channel overflow area") 
to store any information needed to avoid overflowing its internal 
memory capacity. Use of such an interrupt queueing mechanism is 
an optional hardware implementation and not required by the 
architecture. Some channels may have restrictions that guarantee 
that no more than a single interrupt may be outstanding, or the 
channel may have enough internal buffering so that processor's 
memory is not needed. Any such use of the processor's memory is 
transparent except perhaps for initialization of the channel 
overflow area at configuration time. 



7.2.4 Processor- caused Interrupts 



The processor raises an interrupt by setting a bit in the I PR 
through the "INTERRUPT" instruction. The processor will typically 
hold off this interrupt; when the processor later acknowledges the 
interrupt, hardware does not report to software any information 
regarding the interrupt other than the priority level at which the 
interrupt occurred. Software is responsible for any queueing that 
is required to entangle the course of events in case of multiple 
software interrupts. Such queueing must be done before executing 
the INTERRUPT instruction. 
"INTERRUPT pr" sets the appropriate bit in IPR: 

IPR[ pr, i_processor ] := set; 
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7.2.5 Uhen is the Processor Interrupted? 



At the end of an instruction, or at appropriate places in the 
middle of a long instruction, the processor checks to see if 
interrupts should be acknowledged. Interrupts are to be 
acknowledged if the IPR is left "set" at a priority level pr 
that is currently enabled. The algorithm csui be sketched in 
Pciscal as follows: 

if STATUSC.IE = 1 then 

for pr ;= to pr levels-1 do 
if STATUSC.IMRTpr] = 1 then 

for src := i_channel to i_processor do 
if IPR[ pr,src ] = set then 
begin 

IPR[ pr,src ] := clear; 
GO_ACKNOULEDGE_INTERRUPT (pr , src ) ; 
end 



7.2.6 Acknowledging Interrupts 



Section 7.2.5 sketched the algorithm that defines which interrupt, 
if any, must be acknowledged. The algorithm ends either in a 
GO_ACKNOULEDGE_INTERRUPT(pr,src) or it indicates that the flow of 
control should not be changed at all. Detailed below are the steps 
that must be taken when acknowledging the interrupt. 
Note that software arrives at the interrupt handler with values in 
the registers X0..X15 and B0.,B5 that are indeterminate. 



GO_ACKNOULEDGE_INTERRUPT (pr , src ) : 
begin 

STATUSC.IE := 0; 

PUSH_INTERRUPT_MARKER; 

if SIATUSC.ICS = then {a task was interrupted} 

begin 

save S in TCB; 

Q := QI; S := Q; 

STATUSC.ICS := 1; 

end; 
STATUSA.XL := 0; {go to privileged mode} 
if src = i_channel then 

push channel dependent information identifying 

the interrupt; 
PUSH4 pr; 

{all registers X0..X15, BO.. 85 will be indeterminate} 
if src = i_channel then BRX 2 else BBX 3 
end: 
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7.2.7 Shared-memory Itiltiprocessor Considerations 

The interrupt mask register is processor- local, as is the interrupt 
enable/disable bit. More surprising, perhaps, is the fact that the 
interrupt pending register is processor- local. For this to work, 
the following notes apply. 

Note 1: A channel interrupt causes the pending bit to get set in 
the IPR of all processors sharing raenory. 

Note 2: The INTERRUPT instruction must likewise broadcast to all 
processors in order to get the pending bit set in their 
own IPR. 

Note 3: More than one processor may have a particular priority 
level enabled at any one time. In this situation, more 
than one processor will be interrupted. In case of a 
channel interrupt, the data structure that identifies the 
interrupt is shared among all processors; this allows 
only one processor to acknowledge the channel interrupt, 
all other processors will resume their normal instruction 
sequence without ever pushing an interrupt marker. In 
case of a processor interrupt, all enabled processors 
will run the interrupt handler. 

Note 4: Uhen a processor acknowledges an interrupt, it cleaurs 
the pending bit in its own IPR only. This will not 
be broadcast. 
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7.3 Clocks 



There are three clocks supported. Each clock is scaled to give 
results in nanoseconds. However, the actual resolution of the 
clock is implementation dependent and may be much larger than 1 
nanosecond. For example, internally the hardware may count every 
100 nanoseconds but when software reads the clock, the count will 
be scaled to read in nanoseconds. These clocks, when read, return 
a 64-bit 2's complement count. 



7.3.1 Time of Day Clock 



This clock will be used by the system for maintaining the current 
time of day. It runs continuously without interruption and will 
maintain the correct time even across power failure. Ideally, 
this clock will be set only once axvi from that point onwards it 
will continually count up. 

Since 1 Jemuary 1972 there has been an internationally ewjcepted 
time scale based on the International Time Bureau (BIH) standards 
for atomic clocks. The Vision Time of Day Clock will be based on 
this standard. 

The origin (time zero) of this clock is the same as the origin for 
the international reference scale of atomic time (TAI ) , that is, 
1 January 1958 at hours Off (also known as the UTC Reference 
Zone) . The value of this clock is the number of nanoseconds since 
the TAI origin as defined by Coordinated Universal Tine (UTC) . 
Thus, as an example, if it is 4 AM PST then it is 12 Noon UTC as 
there is an eight hour time difference between California and 
Greenwich. For details of this time standard see NBS Special 
Publication 559, "Time and Frequency Users' Manual". Not that it 
is not intended that all Vision computers be as accurate as atomic 
clocks but merely that they agree on what time it is. 



The following functions are provided to support this clock. 

- SET CLOCK (value passed is 64 bits) 

- READ CLOCK (return value is 64 bits) 
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7.3,2 Task Clock 

This clock will be used by the system for accounting purposes. 
This clock counts up and is put in the hold mode whenever control 
is transferred to the Interrupt Control Stack (ICS). It nay also 
be disabled by software by placing it in hold mode. On return 
from the ICS, it resumes counting. 

The following functions cire provided to support this clock. 

- SET CLOCK (value passed is 64 bits) 

- READ CLOCK {return value is 64 bits) 

- HOLD CLOCK 

- RESUME CLOCK 



7.3.3 Interval Clock 



This 64-bit two's-complement clock interrupts the CPU after a 
programmable interval has elapsed. It is used by the system for 
device time-outs, time slicing of processes, etc. The interrupt 
is treated like any other I/O interrupt in the system and is 
therefore subject to being masked off by software. The clock is 
set by loading it with the desired interval, in nanoseconds. 
(It should be a positive interval. A negative interval will losid 
zero into the clock and cause an immediate interrupt.) From there 
on, it counts down until it becomes negative at which time the 
interrupt is generated. The interrupt is signalled to all 
processors in a shared-memory multiprocessor system at a priority 
level that can be configured by software. 

On power-up, the interval clock shall be set to its largest 
positive value. This should prevent any unexpected interrupts 
from being generated by this clock for at least 292 years. 

The following functions are provided to support this clock. 

- SET CLOCK (value passed is 64 bits) 

- READ CLOCK (return value is 64 bits) 
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7.4 Summary of Traps and Internal Interrupts 

The following table is a summary of the internal interrupts and 
traps. Detailed descriptions of each internal interrupt and 
follows in this chapter. For this table, the following notation 
will be used: 



1. ENV ~ Execution environment of handler 

a) CS = current stack 

b) ICS = interrupt control steick 

2. E/D Control — Enable/Disable Control. This indicates 

the control that software has over the 
transfer of control to the handler. 

a) PE = permanently enabled 

b) The status word euid flag(s) that control 
the handler (eg. B2.INT0VFE for fixed 
point overflow) 

3. Parameters — Parameters passed to handler 

a) Pcurrent=Pc = logical address of offending 
instruction. 

b) Pnext=Pn = logical address of the instruc- 
tion following the offending instruction. 

c) Preturn=Pr = the return address in the 
stack marker. 



4. Type 



Type of exception 

a) II = Internal interrupt 

b) NR = non- recoverable trap 

c) R = restartable trap (Pr=Pc) 

d) C = continuable trap (Pr=Pn) 

e) SR = step restaurtable (Pr=Pc) 

f ) SC = step continuable (Pr=Pn) 
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Table of Internal Interrupts and Traps 
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Mnemonic I Trap# | ENV | E/D Control I Type 1 



Parameters 



IIIMEMPAR 

IPOUERFAIL 

IIIPURRCV 

IICPUCHK 

IICSPREPLY 
I CODEBNDSV 
I CODEODTV 
I CODETYPV 
ICODERINGV 
I INSPRIV 
I INSDPSPEC 

INSERROR 

INSCHKLO 

INSCHKHI 

INSUNDEF 

INSXTL 
I INSODDP 
I INSPROBE 

INSMOVSPL 

INSSUITCH 

INSVPPERM 

INSVPICS 
I STKCONSISTV 
I STKOVF 
ISTKUNF 
I STKDEXTV 
I DATABNDSV 
I DATAODTV 
I DATATYPV 
I DATAARV 
IFL-INV 
I FL-DVDZ 
I FL-OVF 
I FL-UNF 
IFL-INX 
i INTDVDZ 
I INTOVF 



1 1 


ICSl 


1 2 


icsl 


1 3 


ICSl 


1 4 


icsi 


1 5 


icsl 


1 6 


cs 1 


1 7 


CS 1 


1 8 


CS 1 


I 9 


CS 1 


1 10 


CS 1 


1 11 


CS 1 


1 12 


CS 1 


1 13 


CS 1 


1 14 


CS 1 


1 15 


CS 1 


1 16 


CS 1 


1 17 


CS 1 


1 18 


CS 1 


1 19 


CS 1 


1 20 


CS 1 


1 21 


CS 1 


1 22 


CS 1 


1 23 


CS 1 


1 24 


ICSl 


1 25 


CS 1 


1 26 


CS 1 


1 27 


CS 1 


1 28 


CS 1 


1 29 


CS 1 


1 30 


CS 1 


1 31 


CS 1 


1 32 


CS 1 


1 33 


CS 1 


1 34 


CS 1 


1 35 


CS 1 


1 36 


CS 1 


1 37 


CS 1 



IPE 
|PE 
IPE 
IPE 
I CI. 
jPE 
IPE 
IPE 
IPE 
IPE 
|PE 
IPE 
IPE 
IPE 
|PE 
IPE 
IPE 
IPE 
IPE 
IPE 
IBI. 
IPE 
IPE 
IPE 
IPE 
IPE 
IPE 
IPE 
IPE 
IPE 
|B2. 
IB2, 
|B2, 
|B2, 
|B2, 
IB2, 
1 32, 



IE 



VPP 



FLINVE 

FLDVDZE 

FLOVFE 

FLUNFE 

FLINXE 

INTDVDZE 

INTOVFE 



II 

II 

II 

II 

II 

R 

R 

R 

R 

R 

R 

C 

C 

C 

R 

C 

NR 

R 

R 

R 

R 

NR 

R 

R 

R 

R 

R 

NR 

R 

R 

C 

C 

C 

C 

C 

C 

C 



Address, Pc,l 

2 

3 

Veiriable,Pc,4 

Status, 5 

Pc,6 

PC, 7 

PC, 8 

Pc,9 

Pc,10 

Pc,ll 

PC, 12 

Pc,13 

Pc,14 

Pc,15 

PC, 16 

PC, 17 

Pc,18 

Pc,19 

Pc,20 

Pc,21 

Pc,22 

Pc,23 

Pc,24 

Pc,25 

PC, 26 

Pc,27 

Address, Pc, 28 

Address, PC, 29 

Address, Pc, 30 

0pl,[0p2],Pc,31 

Qpl,0p2,Pc,32 

Result, Status, Pc, 33 

Result, Status, Pc, 34 

Result, Status, Pc, 35 

Pc,36 

Pc,37 
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Mnemonic I Trap* I ENV | E/D Control! Type I 



Parameters 



DECDVDZ 

DECOVF 

DECINVL 

DECINVDG 

DBBREAK 

DBCALL 

DBCHECKA 

DBCHECKB 

DBSIT 

SEMAOVF 

SEMADOUN 

SEMAUP 

SUITCHN (*1) 

TRYV 

ADRPDIRBND 

ADRPDIR 

ADRPAGEABS 



ADRPAGETOS 



1 38 


CS 1 


1 39 


CS 1 


1 40 


CS 1 


1 41 


CS 1 


1 42 


CS 1 


1 43 


CS 1 


1 44 


CS 1 


1 45 


CS 1 


1 46 


CS 1 


1 47 


CS 1 


1 48 


CS 1 


1 49 


CS 1 


1 50 


CS 1 


1 51 


CS 1 


1 52 


CS 1 


1 53 


CS 1 


1 54 


CS 1 

1 


1 55 


1 

ICSl 

1 



B2.DECDVDZE 


c 1 


B2.DEC0VFE 


c 1 


PE 


R 1 


PE 


R 1 


PE 


C 1 


Bl.PTE 


sc 1 


B2.CB.CBA 


c 1 


B2.CB.CBB 


c 1 


STATUSA.SIT 


c 1 


PE 


R 1 


PE 


c 1 


PE 


C 1 


PE 


c 1 


PE 


R 1 


PE 


R 1 


PE 


R 1 


PE 


R 1 


PE 


R 1 



|Pc,38 

IPC, 39 

IPC, 40 

IPC, 41 

I Operand, Pc, 42 

I PC, 43 

|0percLnd,Pc,44 

I Operand, Pc, 45 

IPC, 46 

I Semaphore, Pc, 47 

I Semaphore , Pc , 48 

I Semaphore, Pc, 49 

IPC, 50 

|Trypointer,Pc,51 

I Entry address, Pc, 52 

I Page number, Pc, 53 

I Byte offset, VPN, 

I Logical address, 

IPC, 54 

I User stack data, 

I Byte offset, VPN, 

j Logical ciddress, 

|Pc,55 



Notes: 

*1: This handler runs on the current stack, but it switches from the 
compatibility mode part of the stack to the native mode part. 
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7.5 Detail Description of Internal Interrupts 



7.5.1 Architectural Interface 



IiThen an internal interrupt is detected, control is transferred 
to the corresponding internal interrupt service routine. The 
methods of transferring control and accessing the interrupt 
service routines are consistent (identical) across all models of 
the Vision family. The following sections describe the details 
of the architectural interface between hardware and software 
(the interrupt service routine). 



7.5.2 Execution Environment 



All internal interrupt handlers enecute on the ICS. 



7.5.3 Sequence of Events 



Uhen an internal interrupt is detected, hardware performs the 
following sequence: 

1) External interrups are disabled. 

2) In case the currently executing instruction is interrupted 
in an intermediate state, intermediate state information 
is pushed onto the stack and the IIP bit in STATUSA is set. 
Otherwise, the step is skipped. (See the description of 
individual instructions for details on interruptible steps). 

3) The current execution stack is capped with an interrupt stack 
marker. 
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4) The following status fields are given standard values: 
(native mode) 
(hold task clock) 



XM 


= 


IIP 


= 


TCE 


= 


DISP 


= 


SIT 


= 


DBP 


= 


ICS 


= 1 


XTL 


= 3 



5) The target location is the entry point in the OD for LOI = 1. 

6) A parameter list is pushed onto the interrupt control 
stack. The description of each internal interrupt 
describes the parameters. The parameters aure pushed 
onto the stack as shown in the following diagram: 

+ + — + 

Q==> I parameter 1 I \ 
+ + \ 

I parameter 2 | \ 

+ + \ Parameter list 

I.I > for internal 

+ + / interrupt 

I . I / handlers 

+ + / 

I parameter n I / 

S==> I 

In all cases the last parameter is the 32-bit Trap*. 

7) The execution environment is set up for executing the 
internal interrupt handler. This involves the following: 

a) The environment registers (Q, S, etc.) are set up 
appropriately for executing code on the ICS. 

All other registers X0,.X15, B0..B5 are left with 
indeterminate values. 

b) The execution privilege level is set to the minimum 
execution level described in the OD corresponding to 
LOI = 1. 

c) A branch (BRX) is performed to the destination 
defined by the logical object id = 1. 

8) Steps 3 through 7 are repeated for each internal interrupt 
detected. 
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7.5.4 Multiple Internal Interrupts 



Multiple internal interrupts are processed by pushing multiple 
interrupt stack markers onto the ICS, Interrupt markers are 
pushed in increasing order of priority. Then execution continues 
by transferring control to the handler for the latest (highest 
priority) internal interrupt. 



Internal interrupts in order of increasing priority axe: 

1) any internal interrupt except power fail and power recovery. 

2) power recovery 

3) power fail 

7.5.5 Internal Interrupts Descriptions 
7.5.5.1 Memory Parity Error 



This internal interrupt is caused when hardware detects a "hard" 
memory error that it cannot resolve without involving software. 

The physical address involved in the access that incurred the error 
is pushed onto the ICS. 

In a shared memory multiprocessor configuration, the parity error 
may not be uniquely attributable to any particular processor's 
memory traffic. Therefore, the parity error may be reported to 
any processor in the configuration. 

Mnemonic: IIMEMPAR 

Parameters: 1. 32-bit physical byte address of the 
location with the parity error 

2. Pcurrent 

3. trap # 
Enabling: permanently enabled 
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7.4.5.2 Power Fail 



Uhen the power system detects a power failure, the power fail 
interrupt is taken. In a shared-memory multi-processor 
configuration, all processors must receive this interrupt. 



Mnemonic : 

Parameter: 

Enabling: 



IIPURFAIL 
trap # 
permanently enabled 



7.5.5.3 Power Recovery 



Uhen power is initially applied to the system, a test of memory 
contents is performed to determine if it contains valid 
information and data. If so, the hardware is initialized 
(including writeable control store) and the power recovery 
interrupt is taken (wsirm start). If memory contents are invalid, 
the machine will perform a cold start. The test for valid memory 
contents is implementation dependent but there will be a finite 
probability of mistaking an invalid memory content as being valid. 
In a shared memory multiprocessor configuration, all processors 
must receive this interrupt. As much as possible, implementations 
must save the machine state across power fail/recovery. 



Mnemonic: 

Parameter: 

Enabling: 



IIPURRCV 
trap # 
permanently enabled 



7.5.5.4 CPU Machine Check 



This trap is defined for the implementation dependent errors that 
a CPU implementation can detect about itself. The information 
reported under this trap classification is specific to each CPU 
implementation. The first parameter is variable in size. Its 
third word is the machine check ID number; this defines how much 
additional information is present. 



Mnemonic: 
Parameter: 



Enabling: 



IICPUCHK 

1. machine check id 

2. Pcurrent 

3. trap # 
permanently enabled 
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7.5.5.5 CSP reply is complete 


markers. The diagram below shows how parameters are pushed: 


Uhen hardware has completed receiving the reply from the CSP to 
the message sent through the MOVEtCSP instruction, this internal 
interrupt is generated. 


+ + — + 

Q==>| parameter 1 I \ 
1 1 \ 


1 — 1 \ 

1 parameter 2 1 \ 


Mnemonic: IICSPREPLY 

Parameters: 1. 32-'bit status (implementation dependent) 

2. trap* 
Enabling: individually enabled (STATUSC.IE) 

7,6 Detail Description of Traps 


1 1 \ Parameter list 

1 . 1 > for trap 


1 1 / handlers 

1.1/ 
1 1 / 


1 1 / 

1 parameter n I / 

S==>| 1 

In all cases the last two parameters are the 64-bit program 
counter Pour rent, and the 32-bit Trap #. 


7.6.1 Architectural Interface 




Uhen a trap is detected by the hardware, control is transferred 
to its corresponding trap service routine. The method of 
transferring control and accessing the trap service routines is 
consistent (identical) across all models of the Vision family. 

Traps provided are also consistent across all models of the 
Vision family. 

The following sections describe the details of the architectural 
interface between the hardware (or microcode) eind the software 
(the trap service routines). 


7.6.3.2 Determining Privilege of the Handler 

The trap handler is a procedure in the Trap object (object 1 in 
group 0). The access rights of the trap object indicate the 
nominal privilege level at which the handler will run. However, 
privilege is never reduced (will never become numerically greater) 
in going to a trap handler. This corresponds to the normal 
procedure calling conventions. 

7.6.3.3 Determining the address of a Trap Handler 


7.6.2 Execution Environment 


The address of the trap handler is defined by code object 1 in 
group 0. 


All trap handlers execute on the current stack except the top of 
stack page fault handler (ADRPAGETOS) which executes on the ICS. 


7.6.4 Sequence of Events 


7.6.3 Common Conventions for Traps 
7.6.3.1 Parameter Passing to Trap Handlers 


The following sections describe the sequence of events involved in 
transferring control to the trap handler. The descriptions rely on 
the conventions set out in the previous section. External and 
internal interrupts are held off during these sequences. 


All traps push their parameters after pushing the procedure stack 
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7.6.4.1 A Non- recoverable Trap on the Current Stack 

Uhen a non-recoverable trap is detected whose trap handler executes 
on the current stack, the following events take place. 

1) The SIT bit in STATUSA is cleared. 

2) An external procedure stack marker is pushed on the stack. 

3) The following status fields are given standard values: 

XM = (native mode) 
DBP = 

4) Q and S are set as expected on a procedure call. 

5) Parameters to the trap handler are pushed on the stack. 

6) P is set to the entry point address of the trap handler 
identified by the trap code object. 

7) STATUSA. XL is set to the privilege level at which the 
handler should run. 

8) Control is passed to the trap handler at P. 



7.6.4.2 A Non-recoverable Trap on the ICS 



Uhen a non-recoverable trap is detected whose handler executes 
on the ICS, the sequence of events is identical to that for an 
internal interrupt. 



7.6.4.3 One Restartable Trap on the Current Stack 
(or a step-restartable trap) 



Uhen a single ijestartable trap is detected whose handler runs 
on the current stack, the sequence of events is the following: 

1) For an interrupted instruction, the intermediate state 
information is pushed, and the IIP bit in STATUSA set. 
Otherwise, this step is skipped. 

2) A stack marker is pushed onto the stack. 
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3) The following status fields sure given standard values: 

IIP = 
SIT = 
XM = (native mode) 

4) Q and S are set as expected on a procedure call. 

5) Parameters for the trap handler are pushed onto the stack. 

6) P is set to the entry point address of the trap handler 
identified by trap code object. 

7) STATUSA. XL is set to the privilege level at which the handler 
should execute. 

8) Control is passed to the trap handler at P. 



7.6.4.4 One Restartable Trap on the ICS 
(or a step-restartable trap) 



This follows the sequence for an internal interrupt; except the P 
value reported corresponds to the current instruction, not the next. 



7.6.4.5 Top-of-stack Page Fault and Stack Overflow 



These follow the sequence for an internal interrupt. Note that these 
faults can occur at any time when pushing stack markers and parameters 
for trap handlers. A description of the sequence of events in this 
case is given in section 7.7. 



7.6.4.6 Multiple Restartable Traps 
(or step-restartable traps) 



Uhen more than one restartable trap is detected, hardware selects one 
and ignores the others. The sequence followed is therefore given by 
one of the sections above. 
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7.6.4.7 Continuable traps 

(or step-continuable traps) 

Continuatle traps can only be detected after restartable traps 
have already been resolved, so continuable traps occur either 
alone or in combination with other continuable traps. Note that 
the breakpoint trap and the single instruction trace trap are 
classified as continuable traps. In addition to these two, only 
one continuable trap can occur in zin instruction. 

Sequence of Events: 

1) Remember the state of the SIT bit in STATUSA. 

2) Clear the SIT bit in STATUSA (SIT=0). 

3) If no other continuable traps except SIT or brealcpoint then 
go to step 11. 

4) If the instruction is step continuable and was interrupted 
at an intermediate step, push intermediate state information 
onto the current stack and set the IIP bit. 

5) Push an external procedure marker. 

6) Clear the IIP flag in STATUSA. 

7) Set Q and S as expected for a procedure call. 

8) Push parameters for the one continuable trap other than SIT or 
breakpoint. 

9) Set P to the entry point address of object 1 in group 0. 

10) Set STATUSA. XL to the privilege level of object 1 in group 0. 

11) If the DBP bit is clear, go to step (18). 

12) Push an external procedure mairker. 

13) Set Q and S as expected in a procedure call. 

14) Push parameters for the breakpoint table trap onto the stack. 

15) Set P to the entry point address of object 1 in group 0. 

16) Set STATUSA. XL to the privilege level of object 1 in group 0. 

17) Reset the DBP bit. 
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18) If the SIT bit was found in step (1) above, go to step (24). 

19) Push an external procedure marker. 

20) Set Q cind S as expected in a procedure call. 

21) Push parameters for the Single Instruction Trace trap. 

22) Set P to the entry point address of object 1 in group 0. 

23) Set STATUSA. XL at the privilege level of object 1 in group 0. 

24) Execute the trap handler at P. 



Note: this sequence may give a DBP trap and an SIT trap before a 
step continuable instruction will have fully completed. These 
trap handlers can either choose to run at this time or they can 
set the SIT bit in the stack marker for the interrupted 
instruction so that the handlers can release control and yet 
regain control back at the end of the instruction. 



7.6.5 System Error 

Certain error conditions are non-recoverable and they cause the 
processor to enter in a special system error state. The 
following conditions cause the processor to enter the 'system 
error' state, 

1) Any trap, such as ODT Length violation, that occurs while 
hardware executes the transfer of control to the trap handler. 

2) Cases like overflow or underflow of the dispatcher disable count. 
In these cases, there is a software error in privileged code. 

3) Bounds violations on the ICS. 

4) TOS page faults when executing on the ICS. 
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7.6.6 Enabling/Disabling Traps 



Traps may be eKplicitly enabled and disabled individually or in 
groups. Traps fall in the following categories. 

1) Permanently Enabled 

These traps are always enabled when the system is up and the 
software is running. These traps cannot be explicitly disabled. 

2) Individually Enabled 

These traps can be explicitly enabled/disabled individually by 
setting/resetting a bit in the STATUSB register. Setting of 
the bit (=1) enables the trap. Resetting the bit (=0) disables 
the trap. 



7.6.7 Transfer of Control Traps 



For the descriptions of the transfer of control traps, these 
notes are applicable: 

1) The Lower Bound (LB) of the object is obtained from the 00 
for the object (third word). 

2) The Upper Bound (UB) of the object is obtained from the OD 
for the object (fourth word). 

3) The Object Length is computed from the OD for the object: 

Object Length = UB - LB + 1 

4) LB and UB are 32-bit 2's complement signed integers; their 
values, however, must be positive. 

5) The Virtual Address of the target location is calculated 
according to the description in chapter 3. Generally, 
the Virtual Offset is computed from the logical offset 
by the calculation: VOFF = LB + LOFF 

6) For instructions BR and CALL, the target code object is always 
the executing code object because these instructions can only 
cause internal transfers. 

7) For instructions BRX, CALLX and EXIT, the target code object 
may be either the executing code object of a different code 
object because these instructions allow both internal and 
external transfers. 
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8) For BRX and CALLX, the target location is obtained from the 
object descriptor of the target code object. 

9) For EXIT, the target location is obtained from the procedure 
stack marker. 



7.6.7.1 Code Object Bounds Violation 



This trap is caused when P points outside the bounds of the code 
object. For instructions that change flow of control, such as 
BR, CALL, CALLX, EXIT, this trap is detected before the next 
instruction is fetched, so that the Pcurrent of the offending 
instruction cam be reported to software. 

Implementations need not detect a Code Object Bounds Violation on 
sequential instruction execution (instructions other than BR, BRX, 
CALL, CALLX, SEXIT, EXIT, lEXIT). It is the responsibility of 
operating system software to guarantee that software cannot "run 
out of theend of a code object". For example, code objects can 
be padded with BREAK instructions. If P is incremented so as to 
become greater than PL on sequential instruction execution, the 
effects may differ across implementations; however, these effects 
will remain limited to the currently executing task. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



CODEBNDSV 

1. Pcurrent 

2. trap # 
restartable 
permemently enabled 



7.6.7.2 Code ODT Length Violation 



This trap is detected for the instructions BRX, CALLX, and EXIT. 
It occurs when an attempt is made to transfer control to an object 
that does not exist; i.e., the object number is greater than the 
number of entries in the ODT of the group selected by the group 
selector in the target logical address. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



CODEODTV 

1. Pcurrent 

2. trap # 
restartable 
permanently enabled 
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7.6.7.3 Code Object Type Violation 



This trap is detected for instructions BRX, CALLX, EXIT and I EXIT 
when an attempt is made to transfer control to an object that is 
not a code object. 



Mnemonic : 
Parameters: 

Trap Type: 
Enabling: 



CODETYPV 

1. Pcurrent 

2. trap # 
restartable 
permanently enabled 



7.6.7.4 Code Privilege Level (Ring) Violation 



This trap is caused for the following cases: 

1) This trap is caused in the EXIT instruction when an attempt 
is made to exit to a privilege level which is more privileged 
thsm the processor's current privilege level (contained in 
the STATUSB register). 

2) This trap is detected for BRX and CALLX when an attempt is 
made to transfer control to a target code object whose 
"prerequisite privilege level' is more privileged than the 
current privilege level. The "prerequisite privilege level' 
of a procedure entry point is contained in the 00 of the 
target object describing the procedure entry point. 



Mnemonic : 
Parameters: 

Trap Type: 
Enabling: 



CODERINGV 

1. Pcurrent 

2. trap # 
restartable 
permanently enabled 
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7.6.8 Instruction Traps 



7.6.8.1 Privileged Instruction Violation 



This trap is caused when an attempt is made to execute am instruction 
at a privilege level which is less privileged than that required by 
the instruction. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



INSPRIV 

1. Pcurrent 

2. trap # 
restartable 
permanently enabled 



7.6.8.2 Error Instruction 



This trap is caused by executing the ERROR instruction. This is 
likely to occur when an error causes P to point to data instead of 
code, i.e., trying to execute data. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



INSERROR 

1. Pcurrent 

2. trap # 
continuable 
permanently enabled 



7.6.8.3 CHECKLO Violation 



This trap is caused when, for the instruction CHECKLO, the first 
operand is smaller than the second operand. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



INSCHKLO 

1. Pcurrent 

2. trap # 
continuable 
permanently enabled 
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7.6.8.4 CHECKHI Violation 


7.6.8.7 Misaligned Program Counter 


This trap is caused when, for the instruction CHECKHI, the first 


This trap occurs when the return address in EXIT, SEXIT or I EXIT 


operand is larger than the second operand. 


is not even, so that P would not be on a half-word boundary. 


Mnemonic: INSCHKHI 


NOTE: This condition may not cause a trap in all implementations; 


Parameters: 1. Pcurrent 


instead, implementations may force P[63]:=0 and continue. 


2. trap # 




Trap Type: continuable 


Mnemonic: INSODDP 


Enabling: permanently enabled 


Parameters: 1. Pcurrent 




2. trap # 




Trap Type: res tar table 




Enabling: permanently enabled 


7.6.8.5 Undefined Instruction 




This trap is caused for all opcodes that are not defined as part of 


7.6.8,8 Probe Violation 


the VISION architecture. 




Mnemonic: INSUNDEF 


This trap is caused for instruction PROBE, when the value of the 


Parameters: 1. Pcurrent 


first operand and/or that of the second operand is/aire illegal. 


2. trap # 




Trap Type: continuable 


Mnemonic: INSPROBE 


Enabling: permanently enabled 


Parameters: 1. Pcurrent 




2. trap # 




Trap Type: restartable 




Enabling: permanently enabled 


7.6.8.6 Exit Threshold Trap 




This trap is caused when the current execution privilege level is 


7.6.8.9 Operand Specifier Violation 


reduced to a level that is less privileged than the level in the 




'XTL' field in STATUSB. 






This trap is caused when an operand specifier in an instruction is 


Mnemonic: INSXTL 


incompatible with the operand attribute expected by the opcode. 


Parameters: 1. Pcurrent 


Example: an operand specifier specifying a literal as a destination 


2. trap # 


in a MOVE instruction. 


Trap Type: continuable 




Enabling: permanently enabled 


Mnemonic: INSOPSPEC 




Parameters: 1. Pcurrent 




2. Trap # 




Trap Type: non-recoverable 




Enabling: permanently enabled 
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7,6.8.10 Move Special Violation 



This trap is caused for the instructions, M0VEfSP4, MOVEfSPS, 
M0VEtSP4, and MOVEtSPS, when the value of the selector is illegal 
and/or when the current privilege level of the processor does not 
match the required privilege level for that value of the selector. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



INSMOVSPL 

1. Pcurrent 

2. trap # 
res tar table 
permanently enabled 



7,6.8.11 Switch Violation 



This trap is detected by all variants of SUITCH when the execution 
environment does not allow a task switch. 



Mnemonic ; 
Parameters: 

Trap Type: 
Enabling: 



INSSUITCH 

1. Pcurrent 

2. trap # 
res tar table 
permanently enabled 



7.6.8.12 VP permission control 



This trap is detected by all vector instructions when a vector 
operation is decoded and the vector permission bits (STATUSB.VPP) 
are zero. That is, the current status does not allow access to the 
vector instructions because the software environment (vector context 
save area) has not been initialized. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



INSVPPERM 

1. Pcurrent 

2. trap # 
res tar table 
individually enabled 
(STATUSBl.VPP) 
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7.6.8.13 Vector Operation on the ICS 



This trap occurs when a vector operation is attempted that uses vector 
registers while executing on the ICS. 

Mnemonic: INSVPICS 
Parameters: 1. Pcurrent 

2. trap # 
Trap Type: non-recoverable 
Enabling: permanently enabled 



7.6.9 Stack Traps 



7.6.9.1 Stack Consistency Violation 



The instruction EXIT is used to restore the caller's environment. 
The registers S, Q are changed to point to new memory locations on 
executing the EXIT instruction. Prior to executing the EXIT instruc- 
tion, checks are made to ensure that the registers SB, Q, S, and SL 
at the end of executing the EXIT instruction would still maintain 
the following stack consistency relationship: 

SB =< Q =< S =< SL 

The Stack Consistency Violation trap is taken when this relationship 
is violated. The I EXIT instruction includes the sane checks. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



STKCONSISTV 

1. Pcurrent 

2. trap # 
restar table 
permanently enabled 



7.6.9.2 Stack Overflow 

This trap is caused when attempting to execute an instruction that 
will result in S pointing at or beyond SL. Note: processing of 
the trap condition follows the sequence of events for internal 
interrupts. The trap handler is executed on the ICS. Uhen this 
exception is detected, S is set according to the following rules: 
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1) If the offending instruction is 'restartable' (see below), the 
is restored to its value prior to the offending instruction. 

2) If the offending instruction is one for which this trap is 
'step restartable', S is restored to its value prior to the 
offending instruction step. 

In either of the above cases, S is rolled back to the appropriate 
position so that the offending instruction can be appropriately 
'restarted' or 'step restarted'. Then the interrupt marker is 
pushed onto the stack according to the rules given in section 7.xx 
(TOS page faults). The overflow part of the marker will go on the 
ICS. At the end of this sequence, S[32..63] in the TCB will point 
to where it would have pointed had the entire interrupt marker been 
pushed onto the user's stack. 

Mnemonic: STKOVF 
Parameters: 1. Pour rent 

2. trap # 
Trap Types: step restartable for instruction DUP 

restartable for other offending instructions 
Enabling: permanently enabled 



7.6.9.3 Stack Underflow 



This trap is caused when an attempt is made to move S below Q 
(i.e. attempt to violate Q[32..63] <= S[32..63]) 



Mnemonic : 
Parameters: 

Trap Type: 
Enabling: 



STKUNF 

1, Pcurrent 

2. trap # 
restartable 
permanently enabled 



7.6.9.4 Delete/Extend Negative Uordcount 

The trap is caused when, for instructions DELETE and EXTEND, the 
wordcount given is negative. 

Mnemonic: STKDEXTV 
Parameters: 1. Pcurrent 

2. trap # 
Trap Type: restartable 
Enabling: permanently enabled 
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7.6.10 Data Object Traps 



For data traps the following terminology is used: 

1) An explict operand is an operand whose logical euidress is 
specified by an operand specifier of the instruction. 

2) A data access is non-explicit when its logical address is 
not directly specified by an operand specifier. The logical 
address of a non-explicit operand is either specified indirectly 
by an explict operamd (as in VCiATHt, VSCATt) or is obtained 
obtained by modifying/indexing the logical address of an 
explicit operand (as in MOVEC). 

3) The Virtual Address of a byte of any operand is computed 
according to the algorithms in chapter 3. 



7.6.10.1 Data Object Bounds Violation 



This trap is caused when the computed (effective) virtual offset 
for an operand (explicit or implicit) is less than the Lower Bound 
LB in the OD for the object or the computed virtual offset is 
greater than the Upper Bound UB minus the size of the data item. 



Mnemonic: 
Parameters: 



Trap Type: 
Enabling: 



DATABNDSV 

1. Offending logical address (64 bits) 

2. Pcurrent 

3. trap # 
restartable 
permanently enabled 



7.6.10.2 Data ODT Length Violation 



This trap is caused when a data eiccess uses a logical address with 
with an object number greater than the number of entries contained 
in the ODT for the selected group. 



Mnemonic: 
Parameters: 



Trap Types: 



Enabling: 



DATAODTV 

1. Offending logical address (64 bits) 

2. Pcurrent 

3. trap # 

non- recoverable for instructions that modify the 
most significant 32 bits of a base register, 
restartable for I EXIT 
permanently enabled 
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7.6.10.3 Data Object Type Violation 


7.6.11.1 Floating Point Invalid Operation 


This trap is caused when an attempt is nieide to access, through a ".w" 


This trap is caused for Floating Point Invalid Operations as defined 


or ".rw" attribute, an object that is not a native node data object. 


in IEEE Floating Point Standard. The operand (s) of the offending 




instruction is (are) pushed. 


Mnemonic: DATATYPV 




Parameters: 1. Offending logical address 


Mnemonic: FL-INV 


2. Pour rent 


Parameters: 1. Operandi 


3. trap # 


(2. cierand2) 


Trap Type: res tar table 


3. Pcurrent 


Enabling: permanently enabled 


4. Trap # 




Trap Type: continuable 




Enabling: individually enabled 




(STATUSB2.FLINVE) 


7.6.10.4 Data Access Rights Violation 




This trap is detected when an attempt is made to access an object 


7.6.11.2 Floating Point Divide By Zero 


while running less privileged than required by the access rights 




field in the OD for the object. 






This trap is caused when the divisor in a floating divide is zero. 


Mnemonic: DATAARV 


The operands are pushed. 


Parameters: 1. Offending logical address (64 bits) 




2. Pcurrent 


Mnemonic: FL-DVDZ 


3. trap # 


Parameters: 1. Operandi 


Trap Type: res tar table 


2. 0perand2 


Enabling: permanently enabled 


3. Pcurrent 




4. Tr^ # 




Trap Type: continuable 




Enabling: individually enabled 


7.6.11 Floating Point Traps 


(STATUSB2.FLDVDZE) 


These traps are detected for Floating Point operations. Their 




implementation is in accordance with IEEE Floating Point Standard. 


7.6.11.3 Floating Point Overflow 


(Refer to "A Proposed Standard for Binary Floating Point Arithmetic" 




draft 9.3.3 of IEEE task P754.) Each trap can be individually 




enabled or disabled with the appropriate bit in STATUSB. Uhen the 


This trap is caused when the magnitude of the result of a floating 


trap condition is detected, the destination operand is set according 


point arithmetic operation is greater than the largest representable 


to the following rules: 


floating point value in the indicated precision. The unrounded 




wrapped result is pushed. The round status is for ROUND=0 and 


1) If the trap is enabled, then the contents of the destination 


STICKY=0, 1 for ROUND=0 and sriCKY=l, 2 for R0UND=1 and STICKY=0, and 


operand are not changed (i.e., remain the same as prior to 


3 for R0UND=1 and STICKY=1. 


executing the offending instruction). 






Mnemonic: FL-OVF 


2) If the trap is disabled, then the contents of the destination 


Parameters: 1. Urapped result 


operand are set as specified in the IEEE standards. 


2. Round status 




3. Pcurrent 




4. trap # 




Trap Type: continuable 




Enabling: individually enabled 
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7.6.11.4 Floating Point Underflow 



This trap is caused for Floating Point Underflow as defined in IEEE 
Floating Point Standard. The wrapped result and round status are 
computed as they are in the overflow case. 



Mnemonic: 
Parameters: 



Trap Type: 
Enabling: 



FL-UNF 

1. Wrapped result 

2. Round status 

3. Pcurrent 

4. trap # 
continual) le 
individually enabled 
(STATUSB2.FLUNFE) 



7,6.11.5 Floating Point Inexact Result 



This trap is caused when the result of a floating point operation is 
inexact as defined by the IEEE Floating Point Standard. The result 
pushed is the rounded or overflowed result. The Round status is as 
in overflow and underflow. 



Mnemonic: 
Parameters: 



Trap Type: 
Enabling: 



FL-INX 

1. Rounded or Overflowed result 

2. Round status 

3. Pcurrent 

4. Trap # 
continuable 
individually enabled 
(STATUSB2.FLINXE) 
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7.6.12 Integer Traps 



7,6.12.1 Fixed Point Divide By Zero 



This trap is caused when an attempt is made to divide an integer by 
zero. Uhen divide by zero is detected, the destination is unchanged. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



INTDVDZ 

1. Pcurrent 

2. trap # 
continuable 
individually erabled 
(STATUSB2.INTDVDZE) 



7.6.12.2 Fixed Point Overflow 



This trap is caused when the result value is outside the allowable 
range of integer values for the destination operand. On overflow in 
ADDt, suet, NEGt, ABSt, ASLt, and MPYt, the lower t bytes of the 
result is returned. For CONVERT the largest positive integer if the 
source was positive and the largest negative integer if the source was 
negative is returned. 



Mnemonic: 
Parameters: 

Trap Type: 
Enabling: 



INTOVF 

1. Pcurrent 

2. trap # 
continuable 
individually enabled 
(STATUSB2.INT0VFE) 
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7.6.13 Decimal Traps 


7.6.13.4 Invalid Decimal Digit 




This trap is detected for some decimal operations when an invalid 


7.6.13.1 Decimal Divide By Zero 


decimal digit is found. See the description of each decimal instruc- 




tion listed below for a list of which characters/digits are invalid 




for that instruction. 


This trap is detected when the divisor is zero in a decimal divide. 




Uhen the divide by zero is detected, the destination operand is not 


Mnemonic: DECINVDG 


changed. 


Parameters: 1. Pcurrent 




2. trap # 


Mnemonic; DECDVDZ 


Trap Type; res tar table 


Parameters: 1. Pcurrent 


Enabling: permanently enabled 


2. trap # 




Trap Type: continuable 




Enabling: individually enabled 




(STATUSB2.DECDVD2E) 


7.6.14 Debug Trap Conditions 


7.6.13.2 Decimal Overflow 


7.6.14.1 Break Instruction 


This trap is detected for decimal operations when the result is larger 


This trap is caused when executing the BREAK instruction. 


than can fit in the destination operand. Uhen the overflow is 




detected, the destination is affected in the following ways: 


Mnemonic: DBBRKINS 




Parameters: 1. Operand 


1) If the trap is enabled, the destination operand is not changed. 


2. Pcurrent 




3. trap # 


2) If the trap is disabled, the result is stored left truncated into 


Trap Type: continuable 


the destination operand. 


Enabling: permanently enabled 


Mnemonic: DECOVF 




Parameters: 1. Pcurrent 




2. trap # 


7.6.14.2 Procedure Trace Trap 


Trap Type: continuable 




Enabling: individually enabled 


This trap is caused at the start of BRX, CALL, or CALLX instructions 


(STATUSB2.DEC0VFE) 


when the PTE bit in STATUSB is found set. 




Mnemonic: DBCALL 




Parameters: 1. Pcurrent 


7.6.13.3 Decimal Invalid Length 


2. trap # 




Trap Type: step continuable 




Enabling: individually enabled 


This trap is detected when the value of the length operand is either 


(STATUSBl.PTE) 


less than zero or greater than 31. 




Mnemonic: DECINVL 




Parameters: 1. Pcurrent 




2. trap # 




Trap Type: res tar table 




Enabling: permanently enabled 
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7.6.14.3 CHECKA Instruction 


7.6.15 Semaphore Traps 


This trap is caused when executing the CHECKA instruction if the bit 




CBA in STATUSB register is set. 


7.6.15.1 Semaphore Overflow 


Mnemonic: DBCHECKA 




Parameters: 1. Instruction operand 


This trap is caused for the instructions UP, DOUN, and TESTDOUN when 


2. Pcurrent 


incrementing or decrementing the 31-bit semaphore value causes a 


3. trap # 


31-bit overflow. 


Trap Type: continuable 




Enabling: individually enabled 


Mnemonic: SEMAOVF 


(STATUSB. CB. CBA) 


Parameters: 1. Logical EUidress of the first operand (semaphore) 




2. Pcurrent 




3. Trap # 




Trap Type: restartable 


7.6.14.4 CHECKB Instruction 


Enabling: permanently enabled 


This trap is caused when executing the CHECKB instruction if the bit 




CBB in STATUSB register is set. 


7.6.15.2 Down Semaphore 


Mnemonic: DBCHECKB 




Parameters: 1. Instruction operand 


This trap is caused for the instruction DOUN, when decrementing the 


2. Pcurrent 


31-bit 2's complement semaphore value of the operzirrf causes it to 


3. trap # 


drop below zero. 


Trap Type: continuable 




Enabling; individually enabled 


Mnemonic: SEMADOUN 


(STATUSB. CB. CBB) 


Parameters: 1. Logical address of the operand (semaphore) 




2. Pcurrent 




3. trap # 




Trap Type: continuable 


7.6.14.5 Single Instruction Trace 


Enabling: permanently enabled 


This trap is caused at the end of executing an instruction when the 




single instruction trace bit (SIT) in the STATUSA register is found 
set. 


7.6.15.3 Up Semaphore 


The SIT bit is always cleared as part of trap initiation. Software 


This trap is caused for the instruction UP, when incrementing the 


must explicitly reenable the single instruction trace by setting 


31-bit 2's complement semaphore value of the operand leaves it at 


the SIT value to one in the stack marker in order to continue single 


or below zero. 


instruction execution. 






Mnemonic: SEMAUP 


Mnemonic: DBSIT 


Parameters: 1. Logical ziddress of the operand (semaphore) 


Parameters: 1. Pcurrent 


2. Pcurrent 


2. trap # 


3. trap # 


Trap Type: continuable 


Trap Type: continuable 


Enabling: individually enabled 


Enabling: permanently enabled 


(STATUSA. SIT) 




7-51 


7-52 



VISION ARCHITECTURE CONTROL DOCUMENT 07/31 




VISION ARCHITECTURE CONTROL DOCUMENT 07/31 


DO NOT COPY — HP PRIVATE INFORMATION 




DO NOT COPY ~ HP PRIVATE INFORMATION 


7.6.16 Vision Mode Switch 


7.6.19 Page Absent Traps 


This trap is the entry point for a switch from HP3000 mode to 






Vision mode. See section 10.5.1.2 for details. 


7.6.19.1 Page Absent 


Mnemonic: SUITCHN 






Parameters: 1. trap # 


This trap is 


caused when a page containing the byte being accessed is 


2. Pcurrent 


not present 


in physical memory. This trap is used for all absent 


Trap Type: continuable 


pages except 


the page on top of the stack; the ADRPAGETOS fault is 


Enabling: permanently enabled 


used for that. ADRPAGEABS is in all respects, including handling 




of pairameters, a normal trap. 




Mnemonic: 


ADRPAGEABS 


7.6.17 TRY/UNTRY Traps 


Parameters: 


1. Byte Offset (POFF) 

2. Virtual Page Number (VPN) 

3. Logical Address (LA) 

4. Pcurrent 


7.6.17.1 TRY or UNTRY Violation 




5. trap # 




Trap Type: 


restartable 




Enabling: 


permanently enabled 


This trap is caused for an illegal TRY or UNTRY instruction. 






This will happen if TRY or UNTRY is used on the ICS. 






Mnemonic: TRYV 


7.6.19.2 Top of Stack Page Absent 


Parameters: 1. TRYoffset 






2. Pcurrent 






3. trap # 


This trap is 


caused when the top of stack page is referenced and is 


Trap Type: restar table 


not present 


in physical memory. 


Enabling: permanently enabled 


This trap is 


very special in that all other traps use the current 




stack to push a marker. The sequence of events for internal 




interrupts is therefore used. The top of stewik page absent handler 




executes on 


the interrupt control stack. 


7.6.18 Virtual Addressing Traps 


More information can be found in section 7.7. 




Mnemonic: 


ADRPAGETOS 




Parameters: 


{0. Overflow Information} 


7.6.18.1 PDINSERT Inconsistent Page Number 




1. Byte Offset (POFF) 

2. Virtual Page Number (VPN) 

3. Logical Address of S (LA) 


This trap is caused for the instruction PDINSERT when the physical 




4. Pcurrent 


page number provided by the instruction does not equal the 




5. trap # 


physical page number contained in the corresponding PDIR entry. 


Trap Type: 


restartable 




Enabling: 


permanently enabled 


Mnemonic: ADRPDIR 






Parameters: 1. Physical Page number in PDIR 






2. Pcurrent 






3. trap # 






Trap Type: restar table 






Enabling: permanently enabled 
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7.7 Top of Stack Page Faults 



All stack objects, except the interrupt control stack, are paged 
objects. Some activities involve pushing information onto the 
stack, including: 

1) an instruction explicitly references the stack as an 
operand; e.g. PUSH, CALL and SWITCH for the Vision mode 
stack and many instructions for the HP3000 mode stack. 

2) an instruction encounters a page absent condition and the 
intermediate state information for the instruction must be 
put on the stack. The instruction in progress (IIP) bit 
described in chapter 4 refers to this case. 

3) an instruction execution results in some conditions that 
are handled as user traps. In this case the instruction 
pushes stack markers as well as parameters for these 
conditions onto the stack. 

4) a condition such as an external interrupt causes a transfer 
of control from the user's stack onto the interrupt control 
stack. In this case an interrupt marker is pushed onto 
the stack. 

However, two obstacles could prevent information from being 
pushed onto the stack: 

1) the page containing the byte pointed to by S is not present 
in physical memory (ADRPAGETOS) 

2) the logical offset S[32..63] attains the length of the stack 
object (UB-LB) . This is the stack overflow condition 
(STKOVF). 

In either case the information normally saved on the stack must 
be saved in a different location. The VISION architecture 
specifies the Interrupt Control Stack of the executing processor 
as the location to store the context when the stack page absent 
condition is detected. In general, the information to be saved 
can be divided into two parts. The illustration on the next 
page shows this: 
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I temporary information 1 
I for the resumption of I 
I execution of the I 
1 instruction I 

+ + 

I interrupt stau:k marker I 



The VISION architecture does not define at which point during an 
instruction a top of stack page absent condition is detected. 
That is, if during pushing any information onto the stack the page 
absent condition is detected, implementations are free to place 
any part of the above information onto the user's stack at S or 
onto the Interrupt Control Stack. In particular, implementations 
are free to push all the above information onto the ICS when it 
detects that not all of it fits onto the user's stack. 

VISION specifies the following to be the same for all hardwEu-e 
implementations : 

1) The value of S stored in the TCB is the sane independent 
of where the information is actually saved. In all cases 
the S value is updated as though the information were 
placed on the user's stack. 

2) The amount of overflow information pushed onto the Interrupt 
Control Stack can be computed as follows: subtract from the 
value of S (pointing into the Interrupt Control Stack) the 
value of QI, and further subtract the length of the argument 
list of the page fault trap handler. 

3) This information must be moved immediately by software from 
the Interrupt Control Stack to some memory resident area so 
that the handler can I EX IT from the ICS. The move can be 
accomplished by a MOVEC instruction using the following 
operands: 

ARGLEN; length of argument list for trap handler (32 bytes) 

SRC: starting cuidress of source information (=QI) 

RES: starting address of some resident destination area 

big enough to receive the information 
L: length of move, computed as: S-QI-ARGLEN 



MOVEC L, SRC, RES 

After the page(s) missing from the user's stack have been 
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brought into physical memory, the information can be moved 
from the memory resident page to the user's stack by MOVEC 
using these operands: 

RES: address of the memory resdient page 
DST: destination area, computed as the S value in the 
TCB minus (Si-QI-LA) where Si is the value of S 
(pointing into the ICS) on entry to the trap handler 
L: same as above 



MOVEC L, RES, DST 



After this move has completed, the user's stack uill appear 
as though the absent page condition had never occurred. 

4) For all of the user's steick markers that were pushed onto 
the ICS, the value of the Qold[32..63] in the stack marker 
is relative to the user's stack and not the ICS. In other 
words, those markers are treated as raw data; they must 
never be used in EXIT or lEXIT when still on the ICS. 



Three cases are sketched with respect to the saving of information. 
The following notation is used in these examples: 



indicates a page boundary 

indicates the boundary value of the base register 

indicates a virtual page present in physical memory 

indicates a virtual page absent from physical memory 

indicates the value of S stored in the TCB after the 

interrupt marker is pushed 

temporary information left on the stack as part of the 

execution of the previous instruction 

denotes the Interrupt Marker 

indicates the value of S after entry to the trap handler 

(points into the ICS) 



Pre 
Abs 
St 

TEMP 

IM 
Si 



7-57 



VISION ARCHITECTURE CONTROL DOCUMENT 
DO NOT COPY ~ HP PRIVATE INFORMATION 



07/31 



Case 1 ~ The stack pages axe present in memory. 



Page 
Status 
+. 

I 
Pre/Abs I 



Stack 
Object 



Q==>l 



Pre 



Stack 
Object 



ICS 



I disp. I 
I marker 1 

QI=>| parms I 

I for trap I 

I handler! 

Si==>+========+ 



Pre 



Pre 



S">|"»== 



St=> 



I I 

I TEMP I 

I INFO I 
++++++++++ 
I IM I 

I 



BEFORE 

INTERRUPT 

MARKER 



AFTER 
INTERRUPT 
MARKER 



Note that in this case the information to restzirt the interrupted 
instruction and the task's interrupt marker fit onto resident 
pages in the task's stack and the only information pushed onto 
the ICS is parameters for the page fault handler. 
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Case 2 ~ The current S page is present but the next virtual page 
is absent. In this case the architecture does not 
define how much information is pushed onto the current 
S page before information is pushed onto the ICS. This 
results in the possibility of the information being 
saved in two parts as shown below. 



Case 2A ~ part of the information is pushed onto the user's stack 



Page Stack 
Status Object 



Pre/Abs 



+----+ 



Pre 



Pre 



Abs 



Q= = > 



S==> 



+----+ 



BEFORE 
INTERRUPT 
MARKER 



Stack ICS 

Object + + 

+ + I disp. I 

I I I marker I 

I I + + 

I I QI=>| part 2 I 

+ + I of IM I 

I I I I 

I I + + 

I I I parms | 

+----+ I for trap! 

!========! 1 handler! 

I Part II + + 

I of IM I Si=>| I 

St=>| I 



AFTER 
INTERRUPT 
MARKER 



The stack page fault handler gets control after the interrupt 
marker part 2 has been pushed onto the ICS. The size of part 
2 can be determined from calculating Si-QI-LA at the entry to 
the page fault handler. 
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Case 2B ~ The current S page is absent. This case includes 
bothwhen the following page is present or absent. 



Page Stack 
Status Object 



Pre/Abs 



Pre 



Abs 



I I 

Q==>l I 

I I 

I I 

S==>|========| 

I I 

I I 



Stack 
Object 



- - - + 



ICS 



+----+ 



Pre/Abs I | St=>| 
I I 

BEFORE 

INTERRUPT 

MARKER 



I dlsp. I 
I marker I 

QI=>| TEMP I 
I INFO I 
I I 
++++++++++ 
+---- + 
I IM I 

Si=>| I 



AFTER 
INTERRUPT 
MARKER 



In this case all of the information is pushed onto the ICS, 
As in Case 2A the amount of information on the ICS can be 
computed from (Si-Qi-LA) at entry to the page fault handler 
on the ICS, 
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7.8 I OS Mechanism 



The Interrupt Control Stack (ICS) is a fiKed size, memory resident 
structure. The location of the ICS is kept in a processor register. 
This location can only be changed through the MOVEtSPS instruction. 

All Vision mode external and internal interrupts execute on the 
ICS. A few Vision mode traps, such as Page Absent, Top of Stack 
Page Absent and Stack overflow, also execute on the ICS. The 
remaining traps are handled on the current task's stack. 

All HP3000 mode internal interrupts as well as HP3000 mode page 
fault traps and stack overflow traps are directed to the Vision 
mode environment to execute on the ICS. The rest of the HP3000 
mode traps are handled on the task's HP3000 mode stack. 
(See the Architectural Control Document for HP3000 Mode for a 
list of the traps supported on VISION. ) 

The dispatcher also executes on the ICS. There is a special stack 
marker permanently located at the bottom of the ICS, known as the 
dispatcher marker. It contains the information necessary to locate 
the dispatcher code and begin execution of the dispatcher, 

Uhile executing on the ICS, the ICS flag in STATUSC is set. The 
flag is set when the ICS environment is established for executing 
the dispatcher or an interrupt service routine. It is cleared by 
the Interrupt Exit Instruction (lEXIT) when it determines that the 
exit is to a procedure that does not execute on the ICS. The 
STATUSC. ICS flag is not directly accessible by any instruction. 

There is a separate ICS for each processor in a shared-memory multi- 
processor configuration. 
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INPUT/OUTPUT DATA STRUCTURES 



CHAPTER 8 



This chapter will eventually describe the data structures that 
must be understood jointly by processor hardware emd by I/O 
hardware. 
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SYSTEM INITIALIZATION 



CHAPTER 9 



9.1 Virtual Object Initialization 



Virtual address space is organized as 2'^32 virtual objects 
of 2"32 bytes each (see section 2.2). 

Virtual Objects 1 through 5 are reserved for special 

areas which are allocated in physical memory and mapped into 

virtual space during system initialization. 



Virtual Object 



SYSCOM 

HASH 
PDIR 
PMEBUF 



(reserved) 

The System Communications Area 

(reserved) 

The Hash Table 

The Physical Page Directory 

The Primary Macro Environment Buffer 



9.2 The System Communications Area 



The System Communications Area (SYSCOM) is a memory resident 
buffer used by hardware and for communications with the Control 
Support Processor (CSP), if available. 

SYSCOM is page aligned in virtual space as virtual object 1. 

The SYSCOM. LENGTH field (+!00) records the total length in bytes 
of SYSCOM. The SYSCOM buffer is organized into sections. The 
number of sections is recorded in the SYSCOM. NUMBER_OF_SECTIONS 
field (+!04). Each section is a physically and virtually 
contiguous subset of SYSCOM, and can be located through a 
descriptor which defines the offset within SYSCOM to the start 
of the section, and the length in bytes of the section. 

Section descriptors are located by fixed section numbers. The 
section number * 8 is the offset in SYSCOM to the section 
descriptor. Once a section is defined in SYSCOM a fixed section 
number is assigned. New implementations nay add sections to 
SYSCOM, but they cannot remove sections. 
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The System Communications Area is partitioned into at least six 
main sections identified below: 



1 SYSCOM, ENV_SECTI ON 

2 SYSCOM.ID_SECTION 

3 SYSCOM. DIAG_SECTION 

4 SYSCOM. HARD_SECTI ON 

5 SYSCOM. LOAD_SECTION 

6 SYSCOM. DUMP SECTION 



Environmental Section 
Identification Section 
Diagnostics Section 
Harware Reserved Section 
Load Section 
Dump Section 



To locate the hardware reserved section of SYSCOM, for example, 
multiply section number 3*8 bytes = !18 bytes offset to the 
section descriptor. 



The System Communications Area 



1 
2 
+-> 3 



SYSCOM. LENGTH 

SYSCOM. NUMBER_OF_SECTI ONS 


(4) 
(4) 


SYSCOM. ENV SECTION. OFFSET 
SYSCOM. ENV_SECTION. LENGfTH 


(4) 
(4) 


SYSCOM. ID SECTION. OFFSET 
SYSCOM, ID_SECTION. LENGTH 


(4) 
(4) 


SYSCOM. HARD SECTION. OFFSET 
SYSCOM . HARD_SECTI ON . LENGTH 


(4) 
(4) 


SYSCOM. DIAG SECTION. OFFSET 
SYSCOM. DIAG_SECTION. LENCTTH 


(4) 
(4) 


SYSCOM. LOAD SECTI ON . OFFSET 
SYSCOM . LOAD_SECTI ON . LENGTH 


(4) 
(4) 


SYSCOM. DUMP SECTION. OFFSET 
SYSCOM. DUMP_SECTI ON . LENGTH 


(4) 
(4) 



00 
04 

08 
OC 

10 
14 

18 

IC 

20 
24 

28 
2C 

30 
134 



9.2.1 The Environment Section of SYSCOM 



The Environment Section of SYSCOM is defined as section number 1 
of SYSCOM and can be located through the section descriptor 
found at an offset of +108 bytes into SYSCOM. 
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SYSCOM.ENV_SECTION 

Number of Processors 
Number of Physical Pages 
Max CSP error log (bytes) 
MaK CSP message log (bytes) 
Max CSP display message (bytes) 



bytes 



(4) 


+ !00 


(4) 


+ !04 


(4) 


+ !08 


(4) 


+ !0C 


(4) 


+ !10 



9.2.2 The Identification Section of SYSCOM 



The Identification Section of SYSCOM is defined as section 
number 2 of SYSCOM and can be located through the section 
descriptor found at an offset of +!10 bytes into SYSCCM. 



1 SYSCOM.ID_SECTION 






1 Firmware ID 


(8) 


+ !00 


1 Firmware Version 


(8) 


+ i08 


1 CSP ID 


(8) 


+ 110 


1 CSP Version 


(8) 


+ !18 


1 CSP Software ID 


(8) 


+ !20 


1 CSP Software Version 


(8) 


+ J28 


1 HPE Software ID 


(8) 


+ !30 


1 HPE Software Version 


(8) 


+ !38 


1 Software ID Object. LA 


(8) 


+ 140 




bytes 
«i^t;^*, 


1 

1 
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9.2.3 The Hardware Reserved Section of SYSCOM 



The Hardware Reserved Section of SYSCOM is defined as section 
number 3 of SYSCOM and can be located through the section 
descriptor found at an offset of +118 bytes into SYSCOM. 

+ + 



07/31 



SYSCOM. HARD SECTION 



CSP- area. OFFSET 
CSP-area. LENGTH 



(4) 
(4) 



+ 100 
+ 104 



+ . 



+ 



bytes 



Offset in Hard section of SYSCOM 



9.2.4 The Diagnostics Section 



The Diagnostics Section of SYSCOM is defined as section number 4 
of SYSCOM and can be located through the section descriptor 
found at an offset of +120 bytes into SYSCOM. 



SYSCOM. DIAG SECTI(»l 



9.2.5 The Load Section of SYSCOM 



The Load Section of SYSCOM is defined as section number 5 
of SYSCOM and can be located through the section descriptor 
found at an offset of +128 bytes into SYSCOM. 



SYSCOM. LOAD_SECTION 

Load Option 

Load Device Specification 

Load Parameters 

Dump Option 

Dump Device Specification 

Dump Parameters 
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9.2.6 The Dump Section of SYSCOM 



The Dump Section of SYSCOM is defined as section number 6 of 
SYSCOM and can be located through the section descriptor found 
at an offset of +!30 bytes into SYSCOM. 

All Vision processors, when not running, cam be made to save 
their current register state into the Dump Section of SYSCOM 
by means not defined in this document. 
Global computer context is deposited into fixed locations. 



1 SYSCOM. DUMP_SECTI ON 






1 HASH. PA 


(4) 


+ !00 


1 HASH. LENGTH 


(4) 


+ i04 


1 PDIR.PA 


(4) 


+ !08 


1 PDIR. LENGTH 


(4) 


+ !0C 


1 Group Descriptor (GDO) 


(16) 


+ !10 


1 STATUSD 


(4) 


+ !20 


1 System Breakrange Descriptor 


(16) 


+ !24 


1 Time of Century Clock 


(8) 


+ !34 


1 SYSCOM. PA 


(4) 


+ !3C 


1 Implementation Dependent . OFFSET 


(4) 


+ !40 


1 Implementation Dependent. LENGTH 


(4) 


+ !44 


1 Processor Arch Record . OFFSET 


(4) 


+ !48 


1 Processor Arch Record . LENGTH 


(4) 


+ !4C 


n^-Po£it ^y^ Hi itn-rs Ca<^+i^M r»f CVCPH* 


bytes 

4 


1 
1 



The Dump Section also contains space for a processor 
architectural dimp record for each processor in the computer. 
The first processor record can be located through the offset and 
length pair located in the dump section (+!44), Additional 
processor records are linked together through the next processor 
field in the processor record (+!D4). A length of bytes is 
used to indicate that no further records follow. 
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1 Processor Architectural Record 


: 


1 STATUSA 


(4) 1 +!00 


1 STATUSBl 


(4) 


+ 104 


1 STATUSB2 


(4) 


+ !08 


1 STATUSCl 


(4) 


+ IOC 


1 STATUSC2 


(4) 


+ !10 


1 QI 


(8) 


+ !14 


1 TCB.LA 


(8) 


+ !1C 


1 TCBX.LA 


(8) 


+ 124 


1 XO .. X15 


(64) 


+ !30 


1 BO .. B5 


(48) 


+ 170 


1 Q 


(8) 


+ 1A0 


1 s 


(8) 


+ 1A8 


1 Program Counter 


(8) 


+ 1B0 


1 Task Clock 


(8) 


+ 1B8 


1 Interval Timer 


(8) 


+ 1C0 


1 Processor Serial Number (*) 


(8) 


+ 1C8 


1 Processor Dependent Record. OFFSET (4) 


+ 1CC 


1 Processor Dependent Record. LENGTH (4) 


+ 1D0 


1 Next Processor Record. OFFSET 


(4) 


+ 1D4 


1 Next Processor Record. LENGTH 


(4) 


+ 1D8 



bytes I 

I 

Offset in Processor Architectural Record -+ 



(*): if supported 



Optional resident contiguous buffers for dumping implementation 
dependent information can be allocated and linked to either the 
global record or to any processor architectural record. A 
length of bytes can be used to skip this option. 
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9.3 The Hash Table and Physical Page Directory 

Virtual Object 

+ + <__ HASH, PA 

I HASH The Hash Table I 

3 I (physically contiguous) I 

I I 

+ + 

+ + <__ PDIR.PA 

I PDIR The Physical Page Directory I 

4 I (physically contiguous) | 



During system initialization all softuiau'e addressable memory is 
mapped into virtual space by hardware. The size and physical 
location of the hash table and the physical page directory are 
committed at this point. 

The hash table (HASH) must be contiguous in physical memory and 
is initially mapped as virtual object 3. The size of HASH is a 
function of memory size and load options. 

The physical page directory (PDIR) must be contiguous in 
physical memory and is initially mapped as virtual object 4, 
The size of PDIR is a function of memory size. 

Hardware may choose to not associate certain phyical pages with 
virtual pages. The virtual page number (VPN) field in PDIR 
entries will be set to by convention to indicate that no virtual 
page association has been made. 
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9.4 The Primary Macro Environment Buffer 



A Primary Macro Environment (PME) is a pre-built, bootable, 
macro code image. 

The Primary Macro Environment Buffer (PMEBUF) is a pre-mapped 
memory resident buffer which will be loaded with a bootable 
macro code image. 



Virtual Object 



PME 

The Primary Macro Environment Buffer 



PMEBUF is contiguous in virtual space and is initially mapped 
as virtual object 5. 

During system initialization hardware allocates a few physical 
pages for SYSCOM, PDIR, and HASH as described in sections 9.2 
and 9.3. Then the remaining physical pages are mapped into the 
PME buffer. 

In contrast to SYSCOM, PDIR and HASH, the PME buffer need not 
remain resident in physical memory once software executes. 
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Virtual Object 



1 PME 






1 The Primary Macro Environment 

1 


Buffer 




1 PME. LENGTH 


(4) 1 +100 


1 PME Checksum 


(4) 


+ 104 


1 Group Descriptor (GDO) 


(16) 


+ 108 


1 TCB.LA 


(8) 


+ 118 


1 TCB.VA 


(8) 


+ 120 


1 QI.LA 


(8) 


+ 128 


1 QI.VA 


(8) 


+ 130 


1 CST descriptor 


(8) 


+ 138 


1 DST descriptor 
1 


(8) 


+ 140 
+ 148 


1 reserved for expansion 







I Macro Code Image 



+ 1100 



The first 256 bytes of each Primary Macro Environment serve as a 
descriptor of the PME. 

The PME. LENGTH field (10) defines the length of the image in 
bytes and can be used to ensure that the entire image mill fit 
into the pre-mapped buffer. The PME Checksum (14) can be used 
to insure that the image has been properly loaded. 

The group descriptor (GDO +108) defines the location of ODTO 
within the PME. Since the PME is constructed to be loaded into 
PMEBUF, GDO. VON will always be virtual object 5. GDO. LB must be 
page aligned in virtual space. GDO.UB is equal to PME. LENGTH 1. 
GDO.LON will vary from PME to PME. 

The TCB.LA field (118) contains the logical address of a 
pre-built Task Control Block within the PME. TCB.VA (+120) 
contains the virtual address of the TCB. 

The QI.LA field (+128) contains a logical pointer to the 
dispatcher marker on the Interrupt Control Stack. The QI.VA 
field (+130) contains the virtual address of the dispatcher 
marker. 

The CST descriptor (+138) defines the object number in group 
where the CST starts, and the length in bytes of the CST. 

The DST descriptor (+140) defines the object number in group 
where the DST starts, and the length in bytes of the DST. 
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9.5 



The Macro Code Launch 



The following sequence of steps are taken for macro code launch. 

1) Allocate physical pages for PDIR, HASH, SYSCOM, and 
PMEBUF, and nap these virtual objects. 

2) Load the PME into the PMEBUF in memory. 

3) Using the PME descriptor do: 

Set the ODTO registers. Now logical euidressing is 
defined. 

Find the logical and physical address of the TCB. 

Set QI to point into the ICS object. 

Locate the CSTs and the DSTs. 

4) Set the initial state of the processor such that it will 
run uninterrupted at the highest privilege level. See 
section 9.7 for a summary of the initial state. 



The cold load hardware then executes the algorithm described 
under the LAUNCH instruction to initiate the launching of 
software. The task pointed to by the TCB is launched. 
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9.6 Initial State Summary 
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+-+ — + + + + + +-----------+ 
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+ + + + + + + + 

11111 22 33 

034 23459 89 01 

+ + + + + + + — + — + 

STATUSB2 IFPC I TE |CBA|CBB| EF | ICCi I 
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+ + + + + + + — + — + 
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I I 01 I lol 
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5 6 1 

+ + + 

STATUSC2 I I IMR I 

I I I 

+ + + 

3 

12 3 1 

+-+ + ■ + 

STATUSD I IDRLI REVCODE I 

I i I I 

+-+ + + 
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HP/3000 MODE 



CHAPTER 10 



10.1 INTRODUCTION 



A mode of execution is available which provides the software 
architectural environment of the HP/3000 system. This is called 
(HP/3000) COMPATIBILITY mode to distinguish it from the normal 
NATIVE mode of the VISION architecture. 

The complete architectural definition of Compatibility mode is 
divided into two parts; 

First, Chapter 10 describes the relationship between Compatibility 
and Native mode architectures. The purpose is to identify the 
specific features required of the VISION architecture to allow the 
existence of Compatibility mode in a manner which does not affect 
the inherent integrity of Native mode operations. Discussions 
progress from a generalized overview of the Compatibility and 
Native mode environments to the actual detail descriptions of the 
manner by which System and Task control structures of Compatibility 
mode are implemented and managed using the VISION architecture. 

Second, the addendum to the ACD titled 'HP/3000 Compatibility Mode' 
continues the description of Compatibility Mode but from a different 
viewpoint. It provides the complete details of Compatibility mode 
from the perspective of both User and Privileged mode programmers. 
The instruction sets, data structure formats, addressing modes, 
traps, and environmental concepts are described. 
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10.2 ENVIRONMENTAL OVEKVIEU 

The two modes, Native and Compatibility, are very distinct even 
though they coexist and share access to physical resources. 
Instruction formats, data formats, and addressing modes are 
different. In particular, the Native mode architecture supports 
arbitrary byte alignment, a very large address spauie, and a nominal 
four-byte word size, while the Compatibility mode architecture 
requires word alignment, has amoderate size address space, and 
uses a two-byte word size. 

The differences are so extensive that each mode is considered to be 
an independent architectural model designed to support and execute 
User programs in a particular manner. This results in the task 
(process) model being different in each mode. To switch execution 
from one mode to the other is conceptually equivalent to a process 
switch. 

The primary objective of Compatibility mode is to provide aui 
execution environment for User node programs identical to that on the 
HP/3000 system. A secondary objective is to provide an execution 
environment for Privileged mode code subject to the condition that 
there is guaranteed protection against Native mode structures being 
accessed directly from Compatability mode code. To achieve this 
level of security could mean that the privileged mode set of 
instructions available in Compatibility mode are a subset of that 
in the HP/3000 system. These objectives are accommodated as follows: 



On HP/3000 system two types of addressing are provided: 

* Addressing into segmented code and data structures is the most 
common form. In User mode it is the only type and is fully 
bounds checked. In Privileged mode it is not always bounds 
checked. 

* Absolute addressing is allowed only in Privileged mode with 
absolutely ( I ) no checks. 

Compatibility mode provides both types of addressing but does so 
with full protection against unwarranted access into Native mode 
by encapsulating the Compatibility mode environment (address space) 
using the Native mode ODT structures. The formats of Compatibility 
mode ODT descriptors axe identical to Native mode ODT formats. 
Consider the two addressing types: 
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* Segment adddressing - all code and data segments are Native 
objects. The ODT entry contains a type field which specifies 
certain Compatibility segment types. The management of these 
ODTs (CST and DST) is done by Native mode code and (trusted) 
microcode only. Compatibility code accesses the CST and DST 
only through microcode, never directly. 

* Absolute addressing - emulated using a special Native object 
accessible through microcode. Viewed by Native mode it is a 
logical address space. To Compatibility privileged users it 
still looks like the "real' absolute memory. There is no 
correspondence between the absolute addresses used by 3000 
Compatibility mode and the real main memory addresses. 

So now, instructions can be executed safely, but how are the 
Native task and Compatibility process environments related? 
Uithin a logical task domain, there may exist the need to execute 
in both execution modes(in a serial manner, not in parallel). 
In such a case, two physical tasks/processes are apparent j one 
for each mode having unique code and data (stack included) 
structures. The common shareable element is the single Hardware 
Task Control Block (TCB) . Switch mode instructions are provided 
in both nodes to allow an environment switch to occur to the 
other mode. Even though execution switches back and forth between 
modes, each mode in execution is still an instance of executing a 
single logical task. There is one Dispatcher and one Interrupt 
Control Stack (ICS) in the architecture which exist only in Native 
mode and it is capable of launching either task into the appropriate 
mode. 

Launching a task/process into Compatibility mode means establishing 
the Registers which are specifically used by the Compatibility 
instruction sets. The precise mode of execution is determined at 
any time by the XM field of the STATUSC register. 



STATUSC.XM = 
STATUSC. XM = 1 



Native mode 
Compatibility mode 



In summary, Compatibility mode is completely and safely emulated 
under Native architectural control to provide an environment for 
Compatibility mode Users which is almost an exact replica of the 
HP/3000 environment. Certainly, normal (User mode) users do not 
notice any difference. 
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10.3 SYSTEM CONTROL STRUCTURES 

The following Native mode data structures are required to manage 
and control Code segments, Data segments, and Absolute memory for 
Compatibility mode operations; 

* CST - Code Segment Table 

* DST - Data Segment Table 

* ABS - Absolute Memory Object 

These basic tables cannot be accessed directly by Compatibility 
mode Users, they are only accessed by hardwaire to execute the 
appropriate instructions. 



10.3.1 CST - Code Segment Table 



The CST is a contiguous block of entries in the ODT for group 0. 
The ODT entries are of type 4 or 5 'HP3000 mode code object'. 

A CST number from Compatibility mode is converted into the 
appropriate ODT entry by locating the base of the CST block in ODT 
(group 0) and indexing through the ODT entries using the CST number. 

The Base and Length of the CST cure defined at system initialization 
time gmd passed to the microcode using the M0VEtSP8 instruction. 

Base - 29 bit object number pointing to the entry in the ODT 
for group corresponding to CST 0. 

Length - 32 bit integer specifying the length of the CST in bytes 
(0<=Length< =192*16). A zero Length implies the absence 
of a CST. 

They are now protected in dedicated memory from unwarranted software 
access. Microcode uses than to locate the CST and perform bounds 
checking on the CST index. The legal range of the CST index is: 

1 <= CST index <= 191 

An explicit reference to CSI will cause a 'CST Violation' trap 
to occur. 
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10.3.2 DST - Data Segment Table 


10.4 TASK CONTROL STRUCTURES 


The DST is a contiguous block of entries in the ODT for group 0. 




The ODT entries are of type 3 'Data' object. 


10.4.1 CSTX - Code Segment Table Extension 


A DST number from Compatibility mode is converted into the 




appropriate ODT entry by locating the base of the DST block in ODT 


The local code domain defined by the CSTX concept in HP3000 


(group 0) and indexing through the ODT entries using the DST number. 


Compatibility mode is emulated in Native mode as follows: 


The Base and Length of the DST are defined at system initialization 


The CSTX is a contiguous block of entries in the ODT for group 


time and passed to hardware using the MOVEtSPS instruction. 


which have been assigned to a given task. The TCB contains a 




descriptor of the CSTX to define the base of the CSTX euid the 


Base - 29 bit object number pointing to the entry in the ODT 


length of CSTX, to allow conversion of the CST index to the 


for group corresponding to DST 0. 


corresponding ODT entry (see Section 4.10). 


Length - 32 bit integer specifying the length of the CST in bytes. 


The CSTX contains the CST indices in the range 


A zero length implies the absence of a DST. 






192 <= CST index <= 255 


They are nom protected in dedicated memory from unwarranted 




software access. Hardware uses them to locate the DST and perform 


where the first legal entry in the CSTX is CST 193. 


bounds checking on the DST index. An explicit reference to DST 


An explicit reference to CST 192 mill cause a 'Not Code Segment' 


will cause a 'DST Violation' to occur. 


trap to occur. 


10.3.3 ABS - Absolute Memory Object 




The ABS is a special object in group which provides a logical 




representation of Absolute memory to Compatibility mode instructions. 




The ABS is defined at system initialization time and the ODT entry 




used is the ODT entry equivalent to DST which is inaccessible to 




instructions but readily available to hardware. The absence of a 




DST will cause all absolute addressing to fail and generate an 




"Absolute Address Violation' trap. 




It is now protected in dedicated memory from unwarranted software 




access and used only by hardware for all absolute memory references. 




The legal size of the ABS is defined to be: 




<= ABS size < 128KB 




Several instructions require System Global Region type of access 




i.e. through Absolute address 1000 octal. As for all absolute 




addressing, the ABS is used by hardware for such accesses. 
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10.4.2. Interrupt Stack Marker 



The interrupt stack marker is used to mark the upper limit of the 
stack on enternal interrupts, traps, transfers to the Dispatcher, 
and the Switch operation. 

The interrupt marker generated in Compatibility mode is presented 
below. The one for Native mode is presented in Section 5.1.2. 



I 

I (16) 

I (16) 

I (16) 

+ + 

Q.INT— >l DELTA Q I (16) 



X register 
P-PB 
STATUS 
DELTA Q 



compatibility/ 
native mode 
mailboK 



1 DB.DST 


1 


DB. OFFSET 


1 


DL. OFFSET 


1 


Z, OFFSET 


1 


STATUSB 


S.INT— >| 


(S.INT - Q.INT) 



(16) 
(16) 
(16) 
(16) 
(64) 
(16) 
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Notes: 

1) The number in parenthesis following each box reflects the 
appropriate number of bits of specification. 

2) X register, P-PB, STATUS, DELTA Q are the normal contents of 
a Compatibility mode procedural stack marker. 

3) DB.DST =0 if DB set to ABS (absolute memory) 

<> if DB set to stack or data segment 
DB. OFFSET defines the displacement (in units of 16 bits) 
into the corresponding object. 

4) DL. OFFSET, Z, OFFSET are the current values of the DL and Z 
registers given as displacements into the stack object. 

5) STATUSB is the current STATUSB register contents. 

6) S.INT is the interrupted S value stored into TCB.SC. The value 
of Q can be calculated from the contents (S.INT-Q.INT). 
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10.4.3 TCB contents known to Hardware 
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The additional information required in the TCB by the hardware 
to support Compatibility mode instructions and the special 
instructions in Native mode to interface with Compatibility mode 
are specified below. 
See Section 5.8 for complete TCB details. 

CSTX - CSTX descriptor (see 10.4.1) 

m - mode of execution of the task 

= Native mode 
= 1 Compatibility mode 
{ 1 bit ) 

SN - logical address of top-of-stack of Native stack 
when capped by an interrupt stack marker - it 
points to the next byte following the interrupt 
marker . 
( 64 bits ) 

SC - logical address of top-of-stack of Compatibility 

stack when capped by an interrupt stack marker - 
- it points to the last 16-bit word of the 
interrupt stack marker. 
( 64 bits ) 

SHIP - switch in progress flag. 
( 1 bit ) 
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10.5 MODE SUITCHING 



Mode switching refers to the operations which affect the execution 
mode flag XM in the STATUSC register. 

STATUSC.XM = Native mode 
STATUSC. XM = 1 Compatibility mode 

Native mode instructions and/or operations which can initiate a 
switch to Compatibility node are: 

lEXIT 

SWITCH 

RSUITCH 

Compatibility mode instructions and/or operations which cam cause 
a switch to Native mode are: 

SUT 

RSUT 

DISP 

External Interrupts 

ICS Internal Interrupts 

The following operations cause a transfer of execution to the ICS, 
in Native mode, from both Native and Compatibility modes. 

DISP 

External Interrupts 

ICS Internal Interrupts 

The impact of the two modes, Native and Compatibility, on the above 
declared instructions is discussed below. 
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10.5.1 Compatibility Mode Instructions 


10.5.1.2 SUT 


10.5.1.1 DISP 


The SUT instruction provides a switch of the enecution environment 




of a process from Compatibility mode directly to Native mode. 




The Compatibility node stack is capped with an Interrupt Stack 


This instruction is used to enter the Dispatcher directly from 


Marker, the appropriate mode flags changed, and control passed to 


the Compatibility mode process environment. If external interrupts 


the Native SWITCH trap routine on the Native mode stack which 


are disabled then the Dispatcher pending flag is set and execution 


executes above the previous interrupt stack marker. Any 


continues with no switch taking place. 


interferences, such as Page Faults, aborts the operation after 




setting the "switch in progress' flag which then takes effect on 


This is a privileged instruction. 


the subsequent I EXIT to the process. 


if STATUSC.IE = 


This is a privileged instruction. 


then STATUSC.DRF := 1 




else 


if STATUSC.IE =0 


begin 


then Trap" INSSUITOT" 


^PUSH2' X; 


else 


'PUSH2' P-PB; 


begin 


-PUSH2' STATUS: 


'PUSH2' X; 


^PUSH2' (S-Q+2) [0..14] 


"PUSH2' P-PB; 


Q := S; 


"PUSH2' STATUS: 


^PUSH2' DB.DST; 


"PUSH2' (S-Q+2) [0..14]; 


-PUSH2' DB. OFFSET; 


Q := S; 


*PUSH2' DL. OFFSET; 


•PUSH2' DB.DST; 


^PUSH2' Z. OFFSET; 


"PUSH2' DB. OFFSET; 


PUSH8 STATUSB; 


'PUSH2' DL. OFFSET; 


^PUSH2' S-Q+2; 


"PUSH2' Z. OFFSET; 


TCB.SC := S; 


PUSH8 STATUSB; 


STATUSC.ICS := 1; 


"PUSH2' S-Q+2; 


STATUSC.DPF := 0; 


TCB.SC := S; 


execute_case_2_of_IEXIT; 


TCB.XM := 0; 


end; 


TCB.SUIP := 1; 




execute_case_l_of_IEXIT; 




end; 
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10.5.1.3 RSUT 



The RSUT is the reverse operation to a corresponding SUITCH 
instruction which occurred from Native mode and basically returns 
execution control back onto the Native mode stack environment. 
The Compatibility mode stack is capped with a register save to 
build the interrupt stack marker, the process mode flag is set 
to Native mode, and a relaunch of the Native mode process occurs. 



This is a privileged instruction. 

if STATUSC.IE = 
then Trap" INSSUITCH" 
else 



begin 




^PUSH2' 


DB.DST; 


^PUSH2' 


DB. OFFSET; 


'PUSH2' 


DL. OFFSET; 


'PUSH2' 


Z. OFFSET; 


PUSH8 


STATUSB; 


^PUSH2' 


S-Q+2; 


TCB.SC 


:= S; 


TCB.XM 


:= 0; 


execute 


case 1 of I EXIT; 


end; 
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10.5.2 Native Mode Instructions 



10.5.2.1 DISP 



The DISP instruction is described in Section 6.2.9.6. 



10.5.2.2 lEXIT 



The lEXIT instruction is described in Section 6.2.9.8. The 
execution environment of a process is determined first by the 
PM flag, indicating Native or Compatibility mode, and then by 
the SUIP 'switch in progress' flag to either trap to the SUITCH 
Trap routine or just perform a normal launch of the process by 
by reestablishing the registers from the interrupt stack marker. 
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10.5.2.3 SUITCH 



The SUITCH instruction provides a switch of the execution 
environment of a process from Native mode directly to 
Compatibility mode. The Native mode stack is capped with an 
Interrupt Stack Marker, the appropriate mode flags changed, and 
control passed to the Compatibility SUITCH trap routine on the 
Compatibility mode stack which executes above the previous 
interrupt stack marker. Any interference, such as Page Faults, 
aborts the operation after setting the "switch in progress' 
flag which then takes effect on the subsequent lEXIT to the 
process. 

This instruction requires Ring level 1. ^ 

if STATUSC.ICS = 1 or STATUSC.IE = 

then Trap" INSSUITCH" 

else 

begin 

PUSH_INTERRUPT_MARKER ; 

TCB.SN := S; 

TCB.XM := 1; 

TCB.SUIP := 1; 

execute_case_l_of_I EXIT ; 

end; 
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10.5.2.4 RSUITCH 



The RSUITCH is the reverse operation to a corresponding SUT 
instruction which occured from Compatibility mode and basically 
returns execution control back onto the Compatibility mode stack 
environment. The Native mode stack is flushed to leave the old 
interrupt stack marker, the process mode flag set to Compatibility 
node, and a relaunch of the Compatibility mode process occurs. 

This instruction requires Ring level 1. 

if STATUSC.ICS - 1 or STATUSC.IE =0 

then Trap" INSSUITCH" 

else 

begin 

S := Q+120; 

TCB.SN := S; 

TCB.XM := 1; 

execute_case_l_of _I EXIT ; 

end; 
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10 6 PRQTFmON 
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1 SORTED LIST or INbTHUCTIONS | APPENDIX I 


The details of protection are integrated with those of Native 


1 


1 1 


mode objects in Chapter 2. In particular, refer to the discussion 
on object types and ohject access rights. 


_^^ — ._ — 










Section 


Instruction 


10.7 IMPLEMENTATION NOTES 


6.2.2.6 


ABSt source. r, destination.u 




6,2.2.1 


ADDt tem.r, sum.rw 




6.3.3.1 


ADDtD term.r, sum.rw 


1. All Compatibility mode objects, code and data segments, are 


6.2.3.1 


AND4 mask.r4, operand. rw4 


assumed by hardware to be aligned on an even byte boundary. 


6.2.3.7, 


ASLt shiftcount.rl, operand, rw 




6.2.3.9 


ASRt shiftcount.rl, opersmd.ru 




6.2.5.9 


BADD4 term.r4, dest.b 




6,2.5.11 


BCMP4 sourcea.b, sourceb.r4 




6.2.5.12 


BCMP8 sourcea.b, sourceb.rS 




6.2.5.5 


BGET4 source. b, dest.w4 




6.2.5.1 


BGET8 source. b, destination. w8 




6.2.5.4 


BM0VE8 source. b, dest.b 




6.2.5.3 


BMOVEADR source. m, dest.b 




6,2.5.8 


BP0P8.- dest.b 




6.2.5.7 


BPUSH8, source. b 




6.2.6.7 


BREAK parameter. r4 




6.2.6.4 


BRX loi.r4 




6.2.6.1 


BR{GLEU} target. r4 




6.2.5.6 


BSET4 source. r4, dest.b 




6.2.5.2 


BSEI8 source. r8, dest.b 




6.2.5.10 


BSUB4 term.r4, dest.b 




6.2.5.13 


BTEST8 source. b 




6.2,6.2 


CALL target, r4 




6.2.6.3 


CALLX loi.r4 




6.2.6.10 


CHECKA parameter, r4 




6.2.6.11 


CHECKB parameter, r4 




6,2.6.13 


CHECKHI source, r4, hibound,r4 




6.2.6.12 


CHECKLO source, r4, lobound,r4 




6.5.1.2.1 


CHNOP 




6.5.1.2.9 


CIS channel, rl, status, rl 




6,4,6.1 


CLRMR mrselect.rl 




6.2.4.10 


CMPB fillchar, Igtha, srca, Igthb, srcb, index 




6.2.4.3 


CMPC length. r4, stringa.m, stringb.m, index. u4 




6,2.4.11 


CMPT table, fillchar, Igtha, srca, Igthb, srcb, index 




6,2.4.1 


CMPt sourcel.r, source2.r 




6.3.3.5 


CMPtD sourcea.r, sourceb.r 




6.3.3.17 


CVAD length. rl, source. r, dest.w 




6,3.3.18 


CVDA length, rl, source, r, dest.w 




6.3.3.11 


CVDI length.rl, source. r, dest.u8 




6.3.3.12 


CVID length.rl, source. r8, dest.w 
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6.2.8.5 


CVLAtVA operand. ml, virtaddr.utS 








6.2.8.7 


CWAtPP virtaddr.rS, ppn.w4 


6.2.6.9 


NOP 




6.2.1.15 


DELETE wordcount.r4 


6.2.3.2 


N0T4 source. r4, destination. w4 




6.2.9.1 


DISABLE oldi.wl 


6.2.3.3 


0R4 mask.r4, operand. rtii4 




6.2.9.6 


DISP 


6.3.3.15 


OVPUNCH sign.rl, operand. rul 




6.2.2.4 


DIVt divisor. r, dividend. rw 


6.5.1.2.5 


PAR response. wl 




6.3.3.4 


DIVtD divisor. r, quotient.™ 


6.5.1.2.4 


PDA response. ttfl 




6.2.9.18 


DOUN sema.mrtij4 


6.2.8.4 


PDDEL ppn.r4 




6.2.1.6 


DPF value. r4, shiftcount.rl, mask.r4, target. ru4 


6.2.8.3 


PDINS ppn.r4 




6.2.1.12 


DUP uordcount.r4, value. r 4 


6.2.2.9 


POLYt degree. rl, polyn.nr, operand. rw 




6.2.9.2 


ENABLE oldi.rl 


6.2.1.5 


POPt destination.© 




6.2.6.8 


ERROR 


6.5.1.2.3 


PRD response. wl 




6.2.6.5 


EXIT 


6.2.8.1 


PROBE ring.rl, access. rl, address. r8, length. r4 




6.2.1.14 


EXTEND uordcount.r4 


6.2.9.4 


PSDB 




6.3.3.14 


GETSIGN operand. rl, sign.wl 


6.2.9.5 


PSEB 




6.2.8.8 


GrowGDO neulength. r4 


6.2.1.4 


PUSHADR operand. n 




6.2.8.6 


HASH virtaddr.rS, hashindex.w4 


6.2.1.3 


PUSHt source. r 




6.2.9.11 


IDLE 


6.4.5.6 


PUVCSA tcb.nr 




6.2.9.8 


lEXIT 


6.2.3.8 


QUAD4 source. r4, destination. u4 




6.5.1.1.1 


IFC 


6.5.1.1.4 


RBYTE data.wl 




6.2.9.3 


INTERRUPT pr.r4 


6.5.1.2.2 


RCL response. Ml 




6.5.2.1.3 


IOC channel. r4, control. r4 


6.5.1.2.6 


RDP channel. rl, dest,wl6, length.wl 




6.5.2.1.2 


I OR channel. r4, control. r4, data.u4 


6.2.2.7 


REMt divisor. r, dividend. rw 




6.5.2.1.1 


lOU channel. r4, control. r4, data.r4 


6.2.1.13 


REP Mordcount.r4, value. r4, operand. nw 




6.4.5.7 


IVB tcb.nr 


6.5.1.2.8 


RIS channel. rl, status. wl 




6.2.9.7 


LAUNCH tcbla.rS, tcbva.rS 


6.2.9.10 


RSUITCH 




6.4.6.3 


LDMR nrselect.rl, source. rl6 


6.4.5.1 


RVLR 




6.4.5.2 


LDVLR source. r4 


6.2.4.9 


SCANUNTIL charset.nr, string. nr, index. rw4 




6.2.3.5 


LSLt shiftcount.rl, bitfield. rw 


6.2.6.6 


SEXIT 




6.2.3.6 


LSRt shiftcount.rl, bitfield. irtii 


6.5.1.2.10 


SIS channel. rl, status. rl 




6.4.5.8 


LVB tcb.nr 


6.3.3.7 


SLD ^ount;rl, length.rl, source. r, dest.w 




6.2.2.8 


MODt divisor. r, dividend. rw 


6.3.3.8 


SRD count. rl, lenght.rl, source. r, dest.w 




6.2.1.2 


MOVEADR operand. m, destination. w8 


6,4.6.2 


STMR nrselect.rl, destination. wl6 




6.2.1.8 


MOVEBIT bitindex.r4, source. rl, bitarray.nrm 


6.2.9.12 


STOP 




6.2.1.9 


MOVEBLR fillchar, srcl, src, destl, dest 


6.4.5.3 


STVLR dest.w4 




6.2.1.10 


MOVEBRL fillchar, srcl, src, destl, dest 


6.2.2.2 


SUBt tem.r, difference. rw 




6.2,1.7 


MOVEC length. r4, source. nr, destination. nu 


6.3.3.2 


SUBtD tem.r, difference. rw 




6.3.3.9 


MOVED length.rl, source. r, dest. a 


6.2.9.9 


SWITCH 




6.2.9.17 


MOVESEMA source. r4, sema.mui4 


6.2.9.15 


SYNCIB operand. nc, length. r4 




6.2.7.1 


M0VEfSP4 selector. rl, destination. u4 


6.2.9.13 


SYNCOD loi.r4 




6.2.7.3 


M0VEfSP8 selector. rl, destination. u8 


6.2.9.14 


SYNCTCB tcb.rS 




6.2.7.2 


M0VEtSP4 selector. rl, source. r4 


6.2.4.6 


TESTA 




6.2.7.4 


MOVEtSPS selector. rl, source. r8 


6.2.4.7 


TESTB 




6.2.2.3 


MPYt factor. r, product. rw 


6.2.4.8 


TESTBIT bitindex.r4, bitarray.nr 




6.3.3.3 


MPYtD factor. r, product. ni 


6.2.9.19 


TESTDOUN SCTia.nrw4 




6.4.6.5 


MRAND mrasleect.rl, nrbselect.rl 


6.2.4.4 


TESTLSB source. rl 




6.4.6.4 


MRNOT nrselect.rl 


6.2.4.5 


TBST0Y 




6.4.6.6 


MROR nraselect.rl, nrbselect.rl 


6.2.8.2 


TESTREF va.r8 




6.4.6.7 


MRXOR nraselect.rl, nrbselect.rl 


6.2.9.16 


TESTSEMA sena.nrw4, result. w4 




6.2.2.5 


NEGt source. r, destination. w 


6.3.3.13 

6,2.4.2 

6.3.3.6 


TESISTRIP operand. rwl 
TESTt source. r 
TESTtD source. r 
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6.2.1.11 


TRANSL table. nr, length. r4, source. rar, dest.raw 




6.2.7.5 


TRY 




6.2.7.6 


UNTRY destination. w4 




6.2.9.20 


UP seiiia.ranj4 




6.4.5.5 ' 


UVGSA 




'6.4.2.7^ 


VABSt vqual.rl, source. vr, abs.vw 




6,4.4.3 


VACCDt vqual.rlj terms.vr, sunrw 




6.4,4.2 


VACet vqual.rl, terms. vr, sum.rw 




6:4.2.2 


VADDt vqiiai.rl, terna.vr, termb.vri sun.vu 




6.3.3.10 


VALD lengtVi.rl, operand.ru 




6.3.3.16 


VdlH length.rl, operand. rw 




5.4.3.1 


VAND4 vqual.rl, facta. vr, factb.vr, and.vM 




6.4.2.12 


VASLt vqual.rl, shiftcount.vr, target. vu 




6.4.2.13 


VASRt vqual.rl, shiftcount.vr, target. vw 




6.4.4.1 


VCMPt vqual.rl, field.rl, srca.vr, srcb.vr, nrsel.rl 




6.4.4.8 


VCOMPRSt vqual.rl, termd.vr, compressed. vw 




6.4.7.1 


VCONVERT vqual.rl, typer.rl, source. vr,dest,vui 




6.4.2.5 


VDIVt vqual.rl, divd.vr, divsr.vr, quot.vw 




6.4.4.9. 


VEXPNDt vqual.rl, ter?is.vr, expanded. vw 




6.4.4.6 


VEXTt vqual.rl, terns. vr, index. r, , value. w 




6.4.4.10 


VGATHt vqual.rl, source. vr, index. vt, destination.vii 




6. 4; 4. 7 


VINSt vqual.rl, tefms.vu, index. r, heuval.r 




6.4.5.4 


VINVAL vrnask.rl 




6.4.2.10 


VLSLt vqual.rl, shiftcount.vr, target. vru 




6.4.2.11 


VLSRt vqual.rl, shiftcount.vr, target. vrw 




6.4.4.4 


VMAXELt vqual.rl, terms. vr, maxind.w4 




6.4.4.5 


VMINELt vqual.rl, terms. vr, minind.iii4 




6.4.2.9 


VMODt yquai.ri, divd.vr, divsr.vr, mod.vu 




6.4.2.1 


VMOVEt vqual.rl, source. vr, dest.vw 




6.4.2.4 


VMPYt vqual.rl, facta.vr, factb.vr, prod.vw 




6.4.2.6 


VNEGt vqual.rl, source. vr, neg.vw 




6.4.3.2 


yOR4 vqual.rl, terma.vr, termb.vr, or.vw 




6.4.2.8 


VREMt vqual.rl, divd.vr, divsr.vr, ren.vw 




6.4.4.11 


VSCATt vqual.rl, source. vr, index. vr, destination. vw 




6.4.2.3 


VSUBt vqual.rl, terma.vr, termb.vr, diff.vw 




6.4.3.3 


VX0R4 vqual^ri, terma.vr, termb.vr, xor.vw 




6.5.1.1.3 


UBYTE data.ri, end.rl 




6.5.1.1.2 


UCMD commahd(.rl 




6.5.1.2.7 


UDP chatnnel.rl, 4ata.rl6, length.rwl 




6.2.3.4 


X0R4 mask.r4, operand. rw4 
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